Re: memoization and error messages

From: Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>
Cc: guile-devel@gnu.org
Subject: Re: memoization and error messages
Date: Sun, 24 Nov 2002 17:49:27 +0100 (CET)	[thread overview]
Message-ID: <Pine.GSO.4.05.10211241703440.28618-100000@sallust.ida.ing.tu-bs.de> (raw)
In-Reply-To: <20021124125745.GA31397@www>

On Sun, 24 Nov 2002 tomas@fabula.de wrote:

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

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

However, it does impose some restrictions:  Guile will be stricter with
respect to certain R5RS demands.  Further, macro expansion is no longer as
dynamic as it was before.  That is, the point of time when expansion is
handled is known in advance - this was not the case before.

But, for those who depend on dynamic code expansion (i. e. re-expansion of
code whenever a macro changes) there is always eval.  People say they
don't like eval.  But, they like dynamic code expansion, huh?  And, what
are their problems with eval?  Performance considerations?  Isn't it
better to improve speed and cleanliness for 99,9% of the cases, where
dynamic re-expansion is not necessary, instead of inhibiting performance
improvements in order to be able to avoid using eval?

IMO, instead of depending on dynamic code expansion (a, well, not-so-clean
and performance-inhibiting implementation detail of guile), the use of
eval is better, because it is standard and it makes parts of the code
obvious where you depend on dynamic re-expansion.
[rambling off]

Well, don't feel angry for my ramblings above, I was a little bit carried
away when I wrote it :-)  I actually very much appreciate all kinds of
comments with respect to separation of memoization and execution.  I have
learned a lot from your and other people's comments.

Friendly greetings
Dirk

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