[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: my current project: new lalr module
From: |
Nala Ginrut |
Subject: |
Re: Fwd: my current project: new lalr module |
Date: |
Thu, 04 Jun 2015 16:41:31 +0800 |
On Wed, 2015-06-03 at 20:40 -0700, Matt Wette wrote:
> (Accidentally sent to guile-devel.)
>
> Having fun with all the great code, and documentation, in guile 2.
>
> My current project is a lalr module. Last December I wanted to start
> working on an interpreter for modelica in guile. Guile has a lalr
> parser generator (system base lalr). When I started looking at it, I
> was not crazy about the input language. I looked to see if a better
> interface could be pasted on, but the code impenetrable for me. So I
> started coding up my own LALR parser generator. I was hoping it would
> take a month of nights/weekends but ended up taking me close to four
> months. For now I am calling my implementation "lalr1".
cool! it'd be a great tool for our multi-lang plan. ;-)
>
> A major difference between my lalr1 and lalr in guile is that the
> guile
> version is a translation of the C-coded bison tool and mine is a
> from-scratch implementation in Scheme based on algorithms from the
> Dragon Book. (The bison implementation uses the DeRemer-Pennello
> algorithms, yacc does not. I'd guess the bison-based implementation
> will generate a parser generator faster, but I think that is a minor
> advantage.)
>
> Some features of lalr1:
> 0) It's implemented with syntax-rules and syntax-case (versus
> define-macro for lalr).
>
oh~nice
> 1) There is no specification of terminals. Terminals are detected in
> rules (via fenders) as quoted symbols or characters.
> Example of terminals: 'number, #\+
hmm...and strings? Do you have plan to let users choose whether to use
terminals-inference? ;-)
>
> 6) There is a macro to generate lalr1 input language from a
> lalr-parser specification.
>
Yes, that would be great!
Happy hacking!
>
>
>
>
>