On Tue, May 25, 2010 at 3:26 PM, Charles Oliver Nutter <[email protected]> wrote: > On Tue, May 25, 2010 at 1:29 PM, Brian Hurt <[email protected]> wrote: >> I think the lesson here is "make your language unparseable, and no one will >> be able to parse it". My advice to people designing new languages is to >> define their grammar in terms of an LALR(1) parser like yacc, javacc, cup, >> etc. And to not let shift-reduce or reduce-reduce conflicts in. One of the >> big reasons for this is that any language that is parseable sanely in >> LALR(1) is parseable sanely in just about anything else, the converse is not >> necessarily true. Fancier parsers such as LL(k) parsers (for example, >> Bison) or top-down parsers (parsec, etc.) are great for parsing lanuages >> that are hard to parse- the idea is to not make your language such. > > This is certainly true for Ruby. There are a few attempts at LALR > parsers for Ruby, but none of them have been carried through to > production impls. *All* the current mainstream Ruby implementations > use the original LL(k) Bison grammar or a port of it to > platform-specific variants, largely because the language has a lot of > difficult-to-parse contextual syntax. Of course, a lot of that syntax > is exactly what people love about Ruby...so it's sometimes a tough > call.
Actually flip those two values...All MRI+JRuby impls use LALR (I have no idea what GRL is -- bison claims it can generate via this too) whereas all attempts via LL(k) are incomplete (aka via antlr, etc...). One totally bogus bit about MRI's grammar is that it alters a context object while parsing/lexing, so it is not a clean grammar either. It does not have shift or reduce errors, but it is not much better from a specification standpoint. It probably could be cleaned up to not do this but it is already a gigantic grammar. -Tom -- blog: http://blog.enebo.com twitter: tom_enebo mail: [email protected] -- You received this message because you are subscribed to the Google Groups "JVM Languages" 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/jvm-languages?hl=en.
