Re: memoization and error messages

[Daniel Skarda]

> R5RS does allow macro and variable of the same name - in a sense.  For
> example:

  First I must say I have to add "read R5RS more carefully" to my TODO list :)

  As my quick survey revealed, this macro part of R5RS is not consistently
implemented in most scheme implementations - in my opinion it shows that there
is something bad in R5RS.

> (defmacro foo <...>)  ;; after this line, foo is a syntactic keyword
> (foo some-args ...)   ;; foo will be expanded.
> (define foo <some-value>)  ;; after this line, foo is bound to a location
> (foo some-args ...)   ;; foo will not be expanded.
> (define (bar) foo)    ;; bar will refer to foo's binding
> (defmacro foo <...>)  ;; after this line, foo is a syntactic keyword, but:
>                       ;; bar will still refer to foo's _variable_ binding

  And what would do

(define (bar) foo)

  here (after second defmacro foo)? Return variable binding <some-value> or
macro? I rather would vote for simplicity, than for adhering to obscure feature
we find in standard (feature that most people do not care to implement in
"standard" way).

>>   (if (macro? foo)  ; not possible with your modification
>>       ....)
>
> True, but if you would quote foo, this could still be checked.

  No! If you quote foo, it is symbol.

  Current Guile:

   (cond
    ((symbol? x) ...)
    ((procedure? x) ...)
    ((macro? x) ....)

  this code after your proposal would be:

   (cond
    ((procedure? x) ...)
    ((and (symbol? x) (macro? x module))
      ...
    ((symbol? x) ...) ; now users has to remember that this line must be 
written 
                      ; after macro? line..... What an obscure feature...

  do you feel that you simplified programming in Guile?


>>   (define old-foo foo) ; also not possible
>
> But
>     (defmacro old-foo args `(foo ,@args))
> does the trick.  The only problem that we currently have, is that defmacro
> is not able to keep track of the module the definition of foo came from.  
> For a temporary workaround, see my email about preparation for hygienic
> macro expansion.
>
>>   (defmacro foo args
>>     (do something clever with 'old-foo args))
>
> As long as you don't mix up definitions of foo from different modules,
> this would also work with my example above.  

  No, it would not. 

(defmacro foo args blah blah ,,,)

(defmacro old-foo args `(foo ,@args))
(defmacro foo args (blah blah `(old-foo ,@args)))

  ... would cause infinite expansion.

>>   (module-ref (resolve-module '(guile-user)) 'define)
>>     
>>     ; returns the same value as simple "define" - but one line is correct
>>     ; another would be error. Why?
>
> Who says that one line is correct and one is an error?  sure:
>    guile> define
> _would_be_ an error if my local version of eval became official.  Today's
> guile still accepts such a line, as it also accepts the module-ref code.
> If my changes became official, the behaviour of module-ref with respect to
> syntactic keywords might also change.

  Well, IMHO (module-ref foo bar) should NOT be an error because "bar" is
defined in "foo" module (no matter if it is macro or not....). 

  I like about Guile (or scheme) that it lets you to touch everything in one
simple way.

  The "simple way" I understand as the way without many rule exceptions
one has to handle. I think something like: less exceptions in code => shorter
code => few bugs => shorter debugging time => faster development.

  "One way" - in guile all values can be "stored in variables" and all variables
are "equal" - why macros should be different? Why do you want to invent new way
for storing values?

>>       (defmacro dynamic-expansion code
>>          `(local-eval '(begin ,@code) (the-environment)))
>>     
>>       so it would be easy to identify the code with dynamic macro expansion. 
>> (I
>>     do not know why people use dynamic macro expansion, but I guess it is 
>> handy
>>     during macro debugging...)
>
> Yes, this could be done, although I recommend that we get rid of
> local-eval.  
  
  I do not care about how "dynamic-expansion" would be implemented.
My implementation with "local-eval" was just an example - such 
"dynamic-expansion"
works even with current guile eval and it clearly marks "odd" code.

> Maybe we are just discussing the wrong examples here:  The major issue
> about first class macros is that you can define them at run-time.  That
> is, you could at run time change the set of syntactic keywords and have
> the same code code expanded in different ways depending on the set of
> macro definitions defined at run-time.  Do you have any situations like
> this in mind?

  No. I do not defend dynamic macro expansion, rather I was speaking for 
"the right to touch everything" (including macros - that's what I understand 
as "macro is first class"). 

  I understand that non-dynamical macro evaluation is vital for Guile speed.
But I can not understand why it is impossible to achieve non-dynamical macro
expansion without loosing "first class macros". How "(is-a? define <macro>)"
or "(class-of let)" lowers the performance and why you want to prohibit it?
  
  Is there any other advantage than

     guile> define
 
  signals an error? In my oppinion it is easy to catch such errors - but what
would our tax? We would complicate other code and make it less immune to
possible bugs.

0.

ps: My small wish for Guile: macrolet (or let-macro - something like
let-syntax). How hard it would be to write macrolet with your eval?