Re: memoization and conditional defines

From: Rob Browning <rlb@defaultvalue.org>
Cc: guile-devel@gnu.org
Subject: Re: memoization and conditional defines
Date: Sat, 09 Nov 2002 11:08:08 -0600	[thread overview]
Message-ID: <87el9usmbr.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <Pine.GSO.4.05.10211090930520.22059-100000@sallust.ida.ing.tu-bs.de> (Dirk Herrmann's message of "Sat, 9 Nov 2002 10:00:49 +0100 (CET)")

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> On-the-fly memoization is what guile currently does.  This does,
> however, slow down evaluation, it complicates the evaluator and it
> does not allow us to write out pre-compiled code in order to speed
> up startup time.

OK, that's pretty much what I expected.

> It took me quite some time to understand the issues involved with
> conditional definitions.  My current effort to separate memoization
> and execution made it clearer to me, because it reflects itself in
> the code for the evaluator if you want to do things right.  This
> made me see one thing: The design decisions hidden in R5RS are
> typically based on very thorough investigations of potential
> problems.  Implementations have to be very careful to deviate from
> these decisions.

No argument here.  That's my default assumption as well.

> the cond-expression should be memoized.  However, for eval it is IMO 
> easier to communicate the problems involved when distinguishing
> compilation and interpretation:  When using eval, people typically
> understand that the evaluated expression can not be pre-compiled.  In
> contrast, conditional definitions seem so natural that people will
> probably not be aware of the problems that are involved.

Agreed.  I'd definitely like to err on the side of making complicated
things clearer, so I'd favor making eval explicit as you suggest, and
(as I've probably said elsewhere) I'd definitely like to avoid
clevernesses or conveniences that make it harder know when you're
writing code that can be optimized.

> It should be noted that internal definitions may also only occur at a
> restricted set of places.  For example, even the current guile (which
> allows conditional defines on the top level) does not support the
> following:
>   (lambda foo
>     (if <condition> (define <foo> <bar>)))

Ahh, that's what was confusing me.  I took your "let's are ok" too
broadly and I was wondering why

  (let ()
    (if <condition> (define => #t))
    (cond (#t => 'ok)))

would be fine.  Since that's not fine, I'm not confused :>

Thanks for the explanations.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu

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