Colm programming language released: best parser-writer ever

Post by haberman » Wed, May 18, 2011, 10:23 PM UTC

danellis wrote: post #37

haberman wrote: post #18

From my quick scan of the thesis, the basic design seems to be a programming language in which you write both the parser and any transformations you want to perform. It's not clear whether there is an easily-accessible parse tree serialization that you can use to load the output into another language, or whether you'd have to invent that yourself. I think it's generally a hard sell if you try to convince people that…

What you're describing sounds like the Gold parser: http://www.devincook.com/goldparser/

Post by chocolateboy » Thu, May 19, 2011, 9:06 AM UTC

audreyt wrote: post #12

colomon wrote: post #6

It would be interesting to see someone who understood both this and Perl 6's grammars to do a comparison. Based on Colm's quick description and my rough understanding of Perl 6 grammars, they sound like they are roughly equally powerful. But I admit I'm not sure I understand what "transformation language" means...

Although similar in expressive power, Colm offers instruction logging to auto-reverse global state changes upon backtracking, something Perl 6 grammars does not (yet) support; at the moment we need to manually manage them with embedded blocks.

Post by haberman » Sat, May 21, 2011, 6:38 AM UTC

beza1e1 wrote: post #44

haberman wrote: post #24

Earlier quoted context omitted.

ANTLR is not the same as what I am describing. ANTLR generates code in each target language: I am talking about a common runtime that all languages call into. Think of it as a "parsing VM." Using this scheme, there would be no need to have separate backends for C and Java, the only thing you'd need to port is the bindings.

Why would that be a good idea? What advantage would a just-in-time parser generator have that a static parser generator does not?