[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Planning work
From: |
Marius Vollmer |
Subject: |
Re: Planning work |
Date: |
02 May 2001 14:46:53 +0200 |
User-agent: |
Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 |
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?
- Re: Planning work, Marius Vollmer, 2001/05/01
- Re: Planning work, Thomas Bushnell, BSG, 2001/05/01
- Re: Planning work,
Marius Vollmer <=
- Re: Planning work, Thomas Bushnell, BSG, 2001/05/02
- Re: Planning work, Rob Browning, 2001/05/04
- Re: Planning work, Martin Grabmueller, 2001/05/04
- Re: Planning work, Rob Browning, 2001/05/05
- Re: Planning work, Martin Grabmueller, 2001/05/05
- Re: Planning work, Michael Livshin, 2001/05/05
- Re: Planning work, Rob Browning, 2001/05/05
- Re: Planning work, Marius Vollmer, 2001/05/05
- Re: Planning work, Rob Browning, 2001/05/05
- Re: Planning work, Keisuke Nishida, 2001/05/06