Right ... I always found combinator parsers a very nice fit for BNF. I agree these parser are not trivial but I still like them a lot :)
Br's, Marius On May 5, 5:48 pm, Meredith Gregory <[email protected]> wrote: > Marius, > > Thanks for the query. Yes, there is a not so subtle point. Take a look at > the > grammar<http://code.google.com/p/rlambda/source/browse/trunk/src/main/bnfc/rl...>. > To my way of thinking, these are it's advantages. > > - Readable (and therefore maintainable) > - Targets the following languages with only 1 small change to the build > process > - Java -- therefore available in Scala, but faster than Scala > - C/C++ > - C# > - F# > - OCaml > - Haskell > - XML > - Generates visitor patterns > > i find the parser combinator stuff certainly idiosyncratic, but nearly > unreadable. i also note that in Haskell, the language (community) that > originated the parser combinator stuff, the parser combinator machinery is > nicely hidden behind a more standard BNF frontend, such as Alex + Happy. > This is the way it should be. > > Best wishes, > > --greg > > > > On Tue, May 5, 2009 at 4:15 AM, marius d. <[email protected]> wrote: > > > Any reason why not using Scala's combinator parsers? ... or this is > > beyond the point of the exercise? > > > Br's > > Marius > > > On May 5, 4:55 am, Meredith Gregory <[email protected]> wrote: > > > Lifted, Scalad and lasses, > > > > Recently Martin passed along a little code challenge regarding scalable > > > abstractions for building a little lambda calculus evaluator. i've > > finally > > > put together a 1st draft response. i've still got a lot of debugging to > > do, > > > but the solution <http://code.google.com/p/rlambda/source/browse/trunk/> > > is > > > end-to-end. > > > > - there is a parser and evaluator hosted inside a lift-based > > > web-container > > > - the parser is built using BNFC and can target > > > Java/C#/OCaml/Haskell/F#/... > > > - the parser comes with visitor pattern support > > > - the evaluator is built in a two-level type style and demonstrates > > that > > > the only OO you need is just enough to make Scala happy -- the > > abstractions > > > are all FP-based > > > > As i said, this is very much a draft and the code falls over most of the > > > time. But, at this point, it's really a pedagogical device and framework > > for > > > hosting and evaluating different solutions. > > > > Again, one the main reasons i see for using Scala is it's seamless > > interop > > > with Java. The OCaml solution is intriguing (though ther are some > > > strangenesses in it that i've yet to grok), but i would like to see that > > > solution hosted in this manner. > > > > Best wishes, > > > > --greg > > > > -- > > > L.G. Meredith > > > Managing Partner > > > Biosimilarity LLC > > > 1219 NW 83rd St > > > Seattle, WA 98117 > > > > +1 206.650.3740 > > > >http://biosimilarity.blogspot.com > > -- > L.G. Meredith > Managing Partner > Biosimilarity LLC > 1219 NW 83rd St > Seattle, WA 98117 > > +1 206.650.3740 > > http://biosimilarity.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
