Re: Planning work

[Thomas Bushnell, BSG]

Marius Vollmer <address@hidden> writes:

> > If there is some such kind of dynamic module necessary, it must be
> > added to Guile ASAP, or my work becomes dead in the water.
> 
> Would you work on such a module as part of your project, or would you
> consider canceling your project when such a module does not appear on
> the scene?

Well, if the module is still needed, I'd work on it, but I thought
there were already decent parser generators around.

> > My work should be machine independent, and be the sort of thing any
> > guile user could immediately start using, without requiring them to
> > compile, install, and all that jazz.
> 
> Which code should not need to be installed, etc?  Your Python
> translator, or the Python code that people will want to run with
> Guile?  I agree that people should not need to specially treat their
> Python code to use it with Guile via your translator, but is it
> realistic to require that the translator not be installed explicitely?

Oh, this is getting confusing.  Terminology will help:

We have the parser generator; I'll call that "buffalo" (it's like a
bison).

Its job is to build a table; I'll call that "tabla".  This is like the
variable part of y.tab.c.

The table is used at run time in conjunction with a little
table-driven parsing program to parse Python code.  The little
table-driven program I'll call "bones" (it does what the Bison
skeleton file does).

And finally, foobiebletch is a program that creates widgets and
frobonicators out of flebetzies; the author of foobiebletch wants to
permit it to be extendable, and so it has guile bindings and is linked
with the standard normal distribution of guile.

Ok now:

I don't care what language buffalo is written in.  Nobody needs it
except the actual developer of the Python translator (me), for the
same reason nobody needs bison to compile GCC except an actual GCC
hacker.

The table's format is unimportant.

But "bones" is really important.  Bones is something that ordinary
guile users are going to run as part of the "python-load" procedure.
It is an absolute requirement that the author of foobiebletch not have
to do anything different in order to support Python: indeed, he does
not even need to know that Python support exists for Guile.

So when python-load calls bones, how does it work?  Well, there are
three ways conceivable:

Way the First: Bones is a C program that needs to be linked in to
foobiebletch when foobiebletch is compiled.  This is out.

Way the Second: Bones is a C program that builds into a shared
library; python-load automatically locates that library, links it into
guile, and calls the function.  

Way the Third: Bones is a scheme program.  It is loaded and run like
any other.

Now, Way the Third is about 59,837,982 times better than Way the
Second.  I want Way the Third.  If, however, Way the Second exists
now, and is part of Guile already, then I'll take that.

There is a huge advantage in not having machine dependent code in any
part of the Python translator.  That is a key argument against Way the
Second, unless bones is part of the normal guile distribution, in
which case it's just part of the machine-language support for Scheme
code.  But I don't want my package to have some little part that must
be compiled from C; I want a *scheme* program.

Thomas