Re: Planning work

[Rob Browning]

Michael Livshin <address@hidden> writes:

> what is the status of Hobbit wrt the FSF?  (i.e. did the original
> author(s) perform the paper-signing dance)?

Hmm.  I didn't realize those issues hadn't already been resolved (or
if I did know, I'd forgotten).

Anyone know?

> I'd absolutely *love* to have this thing in the Guile core -- that
> would mean no more headache about the startup time.  we could
> pre-compile GOOPS & syntax-case, for example.

That might be nice.  Also, I'm wondering if hobbit couldn't fairly
quickly become a functional backend in Marius proposed scheme.  If
it's used *after* macro expansion, most of the things I know of right
now that hobbit has trouble with would be irrelevant.

In fact, I guess it might be possible to break up hobbit somewhat,
using some of its optimization algorithms in Marius compile phase, and
it's generator in the hobbit-specific backend.  i.e. if we're planning
to have:

  sexp -> compiler -> more-primitive-rep -> backend(tranlator) -> evaluator

perhaps some hobbit algorithms would be used in the compiler and
others in the "hobbit" backend which generates .so libraries.

I suppose the above figure is a substantial simplification over what
we'd really have, since the structure (or at least the "what happens
when") would vary depending on the backend.

To some extent I'm thinking out loud here, but does this look like a
semi-reasonable characterization of the various possible backend
"paths"?  I'm just trying to make sure I understand the overall plan.

Below (- - ->) means "time might pass".  i.e. if you're compiling byte
code files that you're saving, there might be a long time between
writing those files and their later evaluation.

i.e. for the current interpreter

  sexp -> compiler -> primitive-rep -> interp-translator -> interpreter

for hobbit

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

for a vm

 sexp -> compiler -> primitive-rep -> vm-translator -> byte-codes ... -> vm

for lightning

 sexp -> compiler -> primitive-rep
   -> lightning-translator -> machine-code - - -> CPU

Of course in the long run, we might want to hybridize some of this, so
that, for example, the vm or the interpreter could use lightning in
cases where it detected something that lightning could be used to
optimize, but that kind of thing seems like an separate issue that
should be handled inside the virtual machine itself, perhaps in
response to markup inserted by the vm-translator, etc.

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