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! > > > > >
