Re: Guile scanners and parsers

[hjstein at bfr dot co dot il (Harvey J. Stein)]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

 >      bigloo procedure: read/rp regular-parser input-port 

I've used bigloo's lexer & parser.  It's pretty good.  But last I
looked (version 1.9) it could use some enhancement.  It doesn't
support error handling.  You can't catch errors, pop a few tokens &
continue.  On the plus side, I think it's a stronger parser than yacc
uses.  And, of course, it's properly suitable for scheme and it
conforms to Olin Shivers's regexp spec.

It also is designed for compilation, in the following sense.  The
forms for generating parsers and lexers are special.  You can't define
a variable whitespace and use it inside a bunch of lexers, for
example.  Thus, the compiler can a priori crunch the lexer or parser
spec.

Assuming that generating the lexers & parsers is time consuming (which
is is in bigloo), then for guile since we don't have a compiler, you'd
probably want to modify it so that you have something like
(generate-lex-specification ...)  and (generate-parse-specification
...) which aren't special forms.  They would crunch the specifications
and output scheme-readable tables for use by the parser.  The idea
being that one could do:

   (define parse-spec (generate-parse-specification ...))

and then use parse-spec in one's code, as in:

   (read/rp parse-spec input-port)

or one could run:

   (generate-parse-specification ...)

in advance (not at run time) and insert the output of the above code
into one's runtime loading module:

   (define parse-spec <whatever the above command generated>)

so as to avoid the cost of generating the parser each time the module
is loaded.

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il