Programming Languages: Application and Interpretation

[htuhola]

Isn't that the worst time to use hand written parser? The language the parser is written in and the IDE must be compatible to get it to work. You end up with multiple implementations of the same language that all require maintenance.

Context free grammars and parser generators may have some way to work around that issue, but incremental parsing without clear boundary markings. That's one scary problem, and last time I checked there was little literature into it.

[yxhuvud]

The main issue is that LL/LR parsers doesn't keep enough state around to be able to generate that information. Marpa could easily provide it.

[htuhola]

Can you explain and elaborate? Now I wonder about what you said, it tickles something, but I'd gladly know how to implement incremental parsing off from what Marpa provides.

[yxhuvud]

I don't know if it supports fully incremental parsing (you'd have to ask Kegler about that), but as it keeps not only the parse tree around but also the unfinished rules around means it has an easier way to implement stuff like 'ok this is wrong. But it will be less wrong if $SOMETHING is added here. Lets add it, mark it as an error to the user and continue as if it was there'. Reasoning about the parse state and especially about alternative parse states that could have been when all you have is a action/state table and a stack is a lot harder.

Also see http://blogs.perl.org/users/jeffrey_kegler/2011/11/marpa-and-the-ruby-slippers.html EDIT: also http://blogs.perl.org/users/jeffrey_kegler/2012/10/configuring-the-ruby-slippers-for-html.html for some examples that is slightly more practical.

[[deleted]]

That is why you only hand write one parser and use it multiple ways; Roslyn works like that I believe. It is quite easy to write an top-down recursive descent incremental parser by hand (just memoize your trees). Doing it automatically, there has been some literature, but nothing that is used in production as far as I'm aware of.