Paul Sheer wrote:
...
> when I came up with the idea i first tried to create
> a parser in python. after rewriting it twice and pulling
> my hair out. i went for flex/bison, with a standard
> off-the-shelf bison grammer for ansi C.
flex/bison is surely the better solution. Parsers are
always a PITA without a generator.
> i mention this because its a more difficult problem
> than you first suspect. consider an expression which
> contains a function call to a function which contains
> a continuation.
>> a parser would have to understand the FULL C grammer to
> work AT ALL.
One could gather this info by an extensive runtime check
and use that in the compiler. There is no need for
a parser which understands it all. You have one: The
CPU does it for you. Just let the system figure out
what needs to be changed. Then just generate that.
And don't worry about cases not caught: Nothing will
happen but that this is not switchable. No problem.
> when you come to passing function pointers around i
> think the whole thing breaks down. its probably possible
> but i havn't thought of how you would do it.
Same as above. I don't care. With an auto-switching
Stackless, and running some version of the test suite,
all reasonable cases can be simulated and caught.
> also, you are looking at a run-time speed deficit of
> about half (thumb suck).
Yes, if you brute-force it and convert everything.
Just do it for the relevant cases, and you're fine.
You are then in the cases which are the heart of
python, and inefficient, anyway, always going through
dicts, parsing arg tuples, all of that. In that context,
the overhead is neglectible.
> personally, my idea was to use the thing as-is rather
> than try compile existing code. For example, i intend
> to add a couple of new C keywords.
Well, that makes sense. On the other hand, handling
existing code would be essential. I would analyse every
extension module that I can get, and produce continuation
versions of the relevant parts. If that could be automated,
it would be a revolution.
> I think you need to see some example input and output
> to get the idea here. looking carefully through the
> output is quite instructive.
Waah. Yes, this is the kind of code I hate the most.
Really ugly, and really not avoidable when you stick with C.
This is exactly what I try to remove from the code base of
Sam's company.
Being able to remove it, and then to re-introduce it by
means of a compiler who does the dirty work would be
really great.
ciao - chris
--
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
_______________________________________________
Stackless mailing list
Stackless at www.tismer.comhttp://www.tismer.com/mailman/listinfo/stackless