expansion, memoization, and evaluation...

[Rob Browning <rlb@defaultvalue.org>]

I thought it might be worthwhile if I made my support of Dirk's recent
work, and my current feelings about the related issues clear, though
I'm certainly ready and willing to change my position(s) if
appropriate.

ATM I'd really like to see guile make a clean separation between
stages of evaluation.  Dirk has suggested perhaps four stages:

  expansion (scheme->intermediate code)
  compilation (intermediate->intermediate)
  memoization-or-compilation (intermediate->{memoized,compiled})
  execution

That arrangement seems like a pretty good initial goal, though I
realize that it may or may not end up being the "final arrangement".

ISTR that some people were concerned that having a separate expansion
stage might cause a performance loss.  My current feeling is that

  - if the performance hit is minimal, and will go away when we can
    write/read pre-expanded (perhaps our first version of .scmc files
    :>) code, then I'd be tempted to just ignore the loss.  I feel
    like the increased clarity of the process, and the potential for
    optimizations/plugging in other compilers, etc. will be likely to
    outweigh the loss.

    Also note that if we have a point where it's easy to get access to
    the post-expansion, but pre-memoization code, it becomes *much*
    easier to add strong, offline compilation to guile.  As an
    example, my impression is that one of hobbit's biggest issues has
    been dealing with macros (define-macro vs defmacro vs syncase).
    If hobbit can be handed the pre-expanded code, it can completely
    ignore macros.

  - if the performance hit is not minimal, but if it's not all that
    hard to add a #define SCM_I_BUILD_WITH_SEPARATE_EXPANSION_STEP,
    then perhaps that would be a good approach for the short term --
    you'd only enable that option if you were experimenting, if you
    were a guile offline compiler, or if you had finally finished a
    compiler whose performance improvements dwarfed the "separate step
    performance loss".

Ideally we'll pick up more than enough performance improvements
elsewhere, given a cleaner infrastructure for people to hack on
(i.e. one that's approachable by more people) to outweigh the
performance loss that having separate evaluation stages might entail.


Another thing I'd like to suggest is that when considering things like
whether or not we should have unmemoization, first-class macros, etc.,
we consider how these things might affect an offline compiler.  If
nothing else, we may not want to structure guile in such a way that we
provide mechanisms that preclude the code from ever being able to be
compiled offline.  Part of the answer is to use eval-when (or
eval-case) appropriately.

Also, though we can structure guile's macros (and other things) to be
arbitrarily dynamic, that doesn't mean we should.  Aside from the
performance costs involved, I feel like we ought to keep an eye on how
our choices affect both the comprehensibility of our implementation
and the scheme code that the end-user may write.

WRT macros, my general impression is that unless you are very clear
about the semantics of your macro system and your evaluation process,
and unless you're reasonably strict in what you allow, you're likely
to preclude much serious compilation because the compiler won't have
the assurances it needs in order to be able to make many substantial
optimizations.  i.e. if you're not careful you can end up with the
compiler having to just convert

  (foo bar baz)

into 

  (eval '(foo bar baz))

or similar, far more often than you'd like, because the compiler can't
be "sure enough" about foo, bar, or baz.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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