Guile compilation (getting started playing around)

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> We can concentrate on just `compile-file' and work out a scheme how to
> make `load' deal with compiled files in addition to source files.
> Then would come the macro expansion pass.  We would probably start
> with `ice/psyntax.ss'.

> > Just having a trivial implementation would be wonderful.  We would
> > finally have a sandbox where we can clear up (and/or decide about)
> > the various important semantics concerning macros/modules/etc. wrt
> > compile and run times.

So, since I have (had?) it working, I'm kinda thinking about making a
dumb hobbit test system (presuming I check out the copyright issues
first and they're OK).

(Though alternate proposals for a better test system are welcome, as
 long as they don't involve a whole lot of open-ended work that I
 might or might not be able to finish anytime soon :>)

i.e. I want to whip up a functional:

  sexp -> compiler -> primitive-rep
    -> hobbit-codegen -> gcc -> .so - - -> dynamic-link

Where in the first incarnation, "compiler" will just be
"pass-through", and primitive-rep will just be normal scheme code.  I
think this is nearly how hobbit works already.

This won't really work right for a lot of the code at first because
macros won't be handled properly, but it seems to me that building a
test harness like this is a good way to get started seeing what the
issues are.

For example, at first I was presuming that wrt macros, in the long run
the hobbit-translator should never even see them, that they should be
expanded completely while generating primitive-rep, but will that
actually work?  What effect would that have on the ability to
re-define macros at runtime (I've seen the threads discussing the
propagation of redefined macros.)?

I also figure setting up a simple test system will immediately raise
issues like "what's the scope/envt of macro expansion?", forcing us to
deal with them -- probably a GOOD THING(TM).

As a practical question, one of the things I recall being discussed
was how code like this should be handled:

  (define *debugging?* #t)
  ...
  (define-macro (ifdebug . code)
    (if *debugging?*
      `(begin ,@code)
      #t))

Should it be allowed?  If so, what should it really do in a full
hobbit-style system where compilation is completely separate from
execution?

Where possible, I would like to be able to come up with some clear and
hopefully simple rules, and then add new constructs whereever needed
to allow control over (and make explicit) when things happen.

For example, perhaps we decide that running arbitrary code at compile
time is a good idea (which is probably true for some special
applications).  If so, then we could introduce new constructs to make
such bits explicit.  i.e.

  (define-at-compile-time foo 42)

or we could consider what other systems like comon lisp (and AIR
RScheme) have done (i.e. constructs like eval-when, etc.) i.e. in CL:

  (eval-when (:compile-toplevel :load-toplevel :execute)
    ..)

I tend to think that whatever solution we choose, being explict rather
than trying to devise a clever DWIM system is often best.

(Oh, and as a general rule of thumb here.  If we can do something
 simple first, and then make it smarter/faster/more-featureful later,
 I'd like to try that.  I don't want to get in the situation of trying
 to invent the all-singing all-dancing Guile Compilation
 Infrastructure before playing around with the practical bits some.

 Unless I figure out a way to magically make myself a whole lot
 smarter/more-knowledgable I am, trying to anticipate everything in
 advance seems like a good way to go nowhere fast.

 I'd like to try things iteratively for a while: discuss, test,
 discuss, test, etc.)

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930