guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memoization and conditional defines


From: tomas
Subject: Re: memoization and conditional defines
Date: Sat, 9 Nov 2002 10:41:25 +0100
User-agent: Mutt/1.3.28i

On Sat, Nov 09, 2002 at 10:00:49AM +0100, Dirk Herrmann wrote:
> On Thu, 7 Nov 2002, Rob Browning wrote:
> 
> > I'm not entirely clear on the issues involved here, but I'd like to
> > be, so please bear with me.

[...]

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

Ah. This half-answers my previous post, but see below.

[...]

> As has been said in previous mails, there are suitable alternatives for
> conditional defines.
> * For the general case
>     (if <test> (define <foo> <bar>))
>   one can use eval:
>     (if <test> (eval '(define <foo> <bar>) (current-module)))
> * The special case
>     (if (not (defined? <foo>)) (define <foo> <bar>))
>   which is probably very common when dealing with configuration issues can
>   be replaced by the following pattern:
>     (define foo-was-defined-before? (defined? '<foo>))
>     (define <foo> (if foo-was-defined-before? <foo> <bar>)

Hmmm. Sounds more or less like what I was proposing, but in my world, these
substitutions would happen automatically. Which might make the code more
readable. Which might open optimization possibilities. Which might as well,
as you point out, obscure the fact that those constructions cost quite a
bit of performance. Hmmm.

>   Note that the helper-variable foo-was-defined-before? is necessary
>   because within a define form the symbol is already bound to a location
>   (according to R5RS), that is we have to remember whether it had been
>   defined before outside of the define form itself.
> 
> 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.

You are in the middle of the rat's nest and have to cope with other's
mumblings. Tanks for your patience :-)

> I favor to force users to use 'eval when trying to realize conditional
> definitions.  The use of eval does not solve the theoretical problem of
> how in the following code
>   (begin
>     (if some-condition (eval '(define => #t) (current-module)))
>     (define (foo x)
>       (cond (x => some-function))))
> 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.

Yep, but...

imagine that some-condition `becomes known', just because the lexical
environment provides a constant binding to a constant (such code might
come out as a result of a macro expansion). Then, this explicit `barrier'
with eval which you are proposing would make further optimizations more
difficult, I think.

Or am I talking total nonsense?

Regards
-- tomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]