Re: memoization and error messages

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:

    Dirk> On Sun, 24 Nov 2002 address@hidden wrote:
    >> That means that macros aren't anymore `first class objects'? What
    >> consequences does this have for meta-programming?

    Dirk> I don't know.  Can you be a little more specific about what you want 
to
    Dirk> accomplish that you can only accomplish with macros as first-class 
objects
    Dirk> (or rather said "accomplish cleanly")?  If so, please provide code
    Dirk> examples that show your approaches.

What about the uses of `macro?' in `fset' in
lang/elisp/internals/fset.scm - how does this code look with your
changes?  (My understanding is that it is no longer possible to pass
around a macro value in a variable - please correct me if that's wrong.)

    Dirk> [rambling on]
    Dirk> It may make sense to point out the following:  Separate in-advance
    Dirk> memoization brings the possibility to speed up evaluation, it allows 
to
    Dirk> store pre-compiled code and thus speed up loading time, and it is a 
great
    Dirk> way to clean up guile's internals and achieve better R5RS conformance.

Agreed, and it paves the way for various kinds of fuller compilation.

    Dirk> But, for those who depend on dynamic code expansion (i. e. 
re-expansion of
    Dirk> code whenever a macro changes) there is always eval.

I think you are probably right that eval is the way forward, so I'll
try to learn to like it :-)  However, I wonder if dynamic expansion
usages actually need local-eval rather than R5RS eval - which is
tricky because local-eval is in a grey area at the moment.
(i.e. Marius called it a `weird critter' :-)

To test this, I offer a challenge (to anyone, not just Dirk): given
define-macro (or defmacro) behaving as Dirk proposes, write a
define-non-memoizing-macro macro that can be used to define a macro
that is expanded every time its containing expression is evaluated.

        Neil