unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: tomas@fabula.de
Cc: tomas@fabula.de, guile-devel@gnu.org
Subject: Re: memoization and error messages
Date: Tue, 26 Nov 2002 11:42:38 +0100	[thread overview]
Message-ID: <20021126104238.GA6739@www> (raw)
In-Reply-To: <Pine.GSO.4.05.10211241703440.28618-100000@sallust.ida.ing.tu-bs.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


  parent reply	other threads:[~2002-11-26 10:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-24 10:43 memoization and error messages Dirk Herrmann
2002-11-24 12:57 ` tomas
2002-11-24 16:49   ` Dirk Herrmann
2002-11-24 22:25     ` Daniel Skarda
2002-11-28 18:02       ` Dirk Herrmann
2002-12-02 20:45         ` Daniel Skarda
2002-12-03  0:09           ` Lynn Winebarger
2002-11-26 10:42     ` tomas [this message]
2002-11-28 19:34     ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021126104238.GA6739@www \
    --to=tomas@fabula.de \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).