Re: Planning work

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> As a standard, I wouldn't like to involve GCC, i.e., invoking GCC for
> every expression you type in the repl, or even for every file you
> `load' during interactive development.  As a means for delivering an
> application, I think it's a possibility.

Right.  You'd still want to be able to just load things quickly during
interactive development (though if the gcc compilation cycle was short
enough -- which I doubt), having it run gcc automagically for each
load might not be a problem.

In any case, we can always keep the normal load during interactive
development and allow people to specify when they want to engage the
heavy equipment :>

> I know what _I_ want! :> Which is a compilation framework for Guile,
> with explicit functions `compile-file', `compile-expression' or
> similar to shake out the interactions between compiplation and our
> module system, and in general to make the possibility of compilation
> an integral aspect of Guile.  Code written for a file compiler is
> different from code written for an interpreter, I think.
> Interactions with macros and modules are different, for example.

OK.  I think I agree with essentially everything you've said here and
in what follows, so the next question is how do we get started?  I'd
really like to have (ASAP), a framework like you've described, even if
for the moment it's nothing more than a more-or-less no-op skeleton.

We can always keep the current "load" and repl as the default so that
no one even needs notice the development work unless they switch it
on.

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.

> The output of the frontend would still be Scheme with few extensions
> for the module system, and we could simply throw this output at our
> existing interpreter.

And tools like hobbit (etc.) may very well have algorithms we can work
in to the frontend to handle various optimizations.

> This is what (ice-9 syntax-case) does now (I think), but viewed from
> a compiler perspective and not from an interpreter perspective.
> 
> The intermediate form is likely not optimal for the interpreter
> (having replaced `(let ((a 1)) ....)' with `((lambda (a) ...) 1)', for
> example, which the interpreter will create a closure for), but I'm
> sure we can improve this.

Sure, and if we can leave the current system functional while we play
with the new framework, then even if it's slower when using the
"current-interpreter backend", that doesn't really seem to matter.

> And we can have a bytecode backend.  And one using Hobbit.  And one
> with Lighning.  We would know what a backend is supposed to do to
> get the interaction with the rest of the system right.

OK, so how do we get started? :>

> For example, I'm unsure about the semantics of code compiled by
> Hobbit, as compared to the same code interpreted when it comes to
> macros or the module system.

Right.  While I've been playing around with hobbit, I've found macros
are the killer.  It only understands defmacro (as I recall), and when
it gets ready to compile a file, the first thing it does is scan the
file to see if it finds any invocations of defmacro.  If it does, then
it actually calls load on the file (to force definition of all the
macros), then hobbit starts over and compiles the file to C normally.

This hack is of course a big problem for many non-trivial files,
especially if those files load other files using functions other than
load, that might not be defined in that file itself (i.e. in gnucash
we use a simple dependency mechanism -- gnc:depend, gnc:support --
which we're eventually going to drop in favor of guile modules).

Basically, the problem is that if any macros are involved, hobbit
really can't be used as a per-file compiler, you have to switch to
just trying to compile your whole project all at once :<

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