Re: Planning work

[Marius Vollmer]

address@hidden (Thomas Bushnell, BSG) writes:

> Marius Vollmer <address@hidden> writes:
> 
> > 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.

I see.  Sorry for being so inquisitive, I just want to get a good
understanding of what you are up to.

> [table driven parser]
>
> 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).
>
> [...]
>
> 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.

Yep.
 
> 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.  

This is possible, as far as Guile is concerned.  I don't know whether
such a program already exists, tho.

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

This is possible as well, of course.
 
> 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.

Why do you think Way the Second is inferiour?  Because you don't want
to touch C code anymore with a stick?  I can understand that, of
course.  Problem is, right now, Scheme code is noticably slower than C
code.

> There is a huge advantage in not having machine dependent code in any
> part of the Python translator.

Would you consider portable C code machine dependent?  Since it must
be compiled first?  How would you like a system where Scheme code can
be compiled to machine code, and people are expected to do this for
reasonable performance of production code?

> 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.

This is a good position to start from, I'd say, but I wouldn't
categorically outrule C code as some later optimization hack.  If it
turns out that by writing a 50 line C function, you can speed up the
loading of Python code by a factor of 20, would you do it?  What speed
improvement would you need to see before going to C?