Re: Parser performance etc.

[Andrew Archibald <aarchiba@calum.csclub.uwaterloo.ca>]

"merry::satchell"@hermes.dra.hmg.gb writes:

> The recent discussion about parser performance for CTAX has bought to mind 
> something that was suggested a few months ago for I think autogen. Rather
> than writing the whole parser/lexer in scheme, why not use the standard 
> free tools (flex/bison or lex/yacc), but have it emit guile code that uses
> say the gh_ interface. Surely the startup and runtime performance will 
> be better. Furthermore, it should ease code re-use, at least for those 
> languages which have an existing parser written this way; only  the   
> code generation would need to be changed. The main difficulty that I
> can see is that flex generates code that is not re-entrant; it might be
> hard to mix several translators

That's a promising idea.  It's certainly a good idea to have a gizmo
which translates a human-readable grammar into a machine-usable one.
And it's almost certainly a good idea to do it once instead of every
time the language is used.  On the other hand, flex and bison input
files include a lot of C code, so directly porting them wouldn't be
very helpful.  In fact, it would be necessary to essentially rewrite
them (IMHO) to generate scheme that was usable --- reentrant,
thread-safe, and generally efficient in a scheme interpreter.  So it
might be better to write something similar, that accepts similar
grammars (or similar enough grammars that one could do a translation
from flex input files to the new tools).  For this, it might be worth
looking at Bigloo's parser stuff, or the original code that it was
based on. 

Separate heaps, freezing, and unexec are definitely useful, though,
regardless of whether we do this. 

Andrew