Re: memoization and conditional defines

[Rob Browning <rlb@defaultvalue.org>]

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

> But: How should a memoizer that is performed _before_ execution know what
> will be correct?  How should it know whether there will be a binding for
> '=>?

It seems like it can't in that case.

I'm not entirely clear on the issues involved here, but I'd like to
be, so please bear with me.  Would it be possible (and make any sense)
to arrange for something like like "just in time" memoization for
top-level forms (as I think Clinton may have suggested), or would that
overly complicate the code?  i.e. don't memoize top-level expressions
until you're ready to execute them.  Such an approach might prevent
those bits from being compiled efficiently, but I suppose the user
could choose whether or not to write things that way.

There's still the question of whether or not we should even allow
non-top-level defines like this, although I can understand the
impulse, esp for configuration related decisions.  I'd say if
supporting them leads to really nasty semantic or implementational
complexities, especially if given suitable alternatives, then perhaps
we shouldn't.

Also, would eval-when based defines still be OK?  I would presume so,
since they're essentially a conditionally included "begin block".

  (eval-when (compile)
    (define => bar))

>  a) be incompatible with R5RS.  This will, however, require us to make it
>     clear for users of guile where and how we deviate from R5RS.  Taking
>     this option will also imply that our macros are not really hygienic.
>     It also means that an interpreted system will behave different than a
>     compiled or memoized system, even if there are no uses of eval or
>     load.

Hope we can avoid that one.

>  b) complicate the memoization process in order to get things right.  An
>     option that we have here is the following:  Top-level forms are not
>     memoized but interpreted.  Memoization is only done whenever a
>     non-top-level scope is entered, like a let-form, or a
>     lambda-expression. The cost of this solution is that in addition to
>     the memoizer and the executor we would need an interpreter.

Why are let forms and lambda expressions excluded?

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