[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memoization and error messages
From: |
Daniel Skarda |
Subject: |
Re: memoization and error messages |
Date: |
Sun, 24 Nov 2002 23:25:03 +0100 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) |
>> 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.