Re: memoization and error messages

[Daniel Skarda <0rfelyus@ucw.cz>]

>> That means that macros aren't anymore `first class objects'? What
>> consequences does this have for meta-programming?
>
> I don't know.  Can you be a little more specific about what you want to
> accomplish that you can only accomplish with macros as first-class objects
> (or rather said "accomplish cleanly")?  If so, please provide code
> examples that show your approaches.

  I am sorry I have not followed all threads about mnemoization, so it is
possible that my notes are a little bit irrelevant.

  Why I think it is good for macros to be "first class objects":

>  guile> define
>  ERROR: In procedure memoization:
>  ERROR: Misplaced syntactic keyword define.
>  ABORT: (syntax-error)

  Does it mean that `define' is unbound? (*) I do not think so - I guess R5RS does
not allow to have macro and variable of the same name. 

  Macros should be in the same namespace as variables are. This is what I
dislike about Common Lisp - it has one namespace for functions and another for
variables. Maybe this is just a programmer's taste - but in my opinion
programming languages should not be designed with "what is easy to implement"
idea in the mind, but rather "programming should be fun". And I do not think it
is fun to add new cases users have to handle.

  These things I would like to be able to write in guile:

  (if (defined? 'my-macro)
      ....)

  (if (macro? foo)  ; not possible with your modification
      ....)

  (define old-foo foo) ; also not possible

  (defmacro foo args
    (do something clever with 'old-foo args))

  (module-ref (resolve-module '(guile-user)) 'define)
    
    ; returns the same value as simple "define" - but one line is correct
    ; another would be error. Why?

  Another important question - if macros were not first class, what consequences
this change would have on module system and its implementation?

  From my point of view macros as "first class objects" and non-dynamic code
expansion are two different things. If you clearly define when macros are
expanded, there is no need to forbid macros to be first class objects.

  My advice:

  1) Preserve macros as "first class objects". When somebody writes "define" or
    (define foo define), maybe he knows what he is doing :-)
    
  2) Clearly define the non-dynamic macro expansion.

  3) Provide macro `dynamic-expansion' - maybe something like this:

      (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...)

0.


(*) Quick survey:
  
  STklos - define is unbound, variable `define' is possible and it is different
           from macro (macro and variable can coexist)

  SCM - same as in guile

  RScheme - special form, can not be referenced, can be redefined

  MzScheme - same as RScheme

  elk - same as guile

  mit-scheme - same as (R|Mz)Scheme

  bigloo - same as STklos.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel