Re: memoization and error messages

[tomas@fabula.de]

On Sun, Nov 24, 2002 at 05:49:27PM +0100, Dirk Herrmann wrote:
> 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.

Sorry to be so unspecific. One could for example imagine doing code
analysis by re-binding `interesting' symbols and then `running' the
code. Or, rendering of SXML by evalling an S-expression: different
stylesheets would correspond to different environments. In a more
general setting: the environment is the `interpretation function'
of a class of S-expressions. Consider this style of programming:

  (case keyword
        ((foo) (do-foo))
        ((bar) (do-bar))
        ((quux) (do-quux))
	...)

versus

  (let ((foo do-foo)
        (bar do-bar)
        (quux do-quux)
        ...)
    (eval keyword))

(yes, I've used eval ;-)

The nice art of the second approach is that you can carry around `canned'
environments and decide last minute what interpretation so use.

The point now is one of finer control. If the second approach means that
*everything* is open (eval as a totally opaque ``memoization barrier''),
then the second variant loses big time. The ideal (I gues a non-attainable
one) would be to let the compiler to find out. Usually I won't rebind car
or let, or define. But sometimes I might have a reason to (and then I'd
be willing to pay the high price. I'd have to anyway).

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

Yes, you are right -- I'm just (weakly) arguing against a clear either-or,
that's why I sometimes talk about partial evaluation (although I have the
impression that the whole monster might be too fat for our purposes ;)

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

The last one is one very important point, I think. Whatever the
implementation is, macro-expansion time should be clear (at least
so clear that the semantics of non-pathological programs is clear,
or rather that it is possible to decide whan a program is non-pathological).


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

It's not to avoid it. It's just trying to give the compiler the possibility
of being `smarter' than just to rely on the user's judgement (especially
important when you face automatically generated code: the `user' might be
especially dumb in those cases ;-)

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

Hey, come on. I do learn a lot from your ramblings. Please *do* ramble on.
> Friendly greetings
> Dirk


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