Hello Robert, (I'm not sure this is suitable for the fonc list but since my impression is > that OMeta will be the parsing framework used in fonc I'll take the risc ;) > )
OMeta is not *the* parsing framework of FONC, but rather an experiment in using pattern-matching as a "swiss army knife" for rapid programming language prototyping. (Disclaimer: this analogy only works if you think of a swiss army knife as a single tool that can do a lot of different things, and not a collection of different tools. :)) FONCers looking for a "parsing framework" should probably look elsewhere, like Ian's much more efficient PEG implementation (see function/examples/peg). I'm reading the OMeta paper (from DLS 07) and trying to understand the > benefits implied by the statement: > > "However, OMeta is not a parser generator; it is a programming language > whose control structure is based on PEGs." > > I have been using my own OO-based PEG-implementation in Ruby (implemented > in Rockit) for some time and it is similar to OMeta in several regards (can > be applied to any "streamable" input, OO inheritance of parsers/grammars > etc). However, Rockit is different in that it uses a Ruby DSL to build a > grammar description which is then executed/interpreted when parsing. Nothing different so far, this is exactly how the OMeta implementation works. Our compiler dynamically converts a grammar (i.e., its textual representation) into an object that can be used to parse (or more generally, pattern-match) whatever input you give it. OMeta seem to take a different approach in which for example the "foreign" > function parses its arguments from the stream before calling the "external" > grammar production/method. In Rockit the foreign call would have been > pre-parsed so that when actually parsing some input, the arguments to > "foreign" would be sent to the foreign method directly. It would be great if someone could elaborate on why OMeta has chosen this > implementation. Is it mostly for implementation reasons (shorter /simpler > implementation) or does it add some actual power to the parsing framework? > I'm not 100% sure this is what you're asking, but here it goes... Earlier versions of OMeta used to pass production arguments on the program stack. While this approach was efficient, it also made it really difficult for the implementation to support productions that pattern-match on their arguments (similar to ML/Haskell functions). By pushing production arguments onto the beginning of the input stream, our current implementation gets this kind of pattern matching for free. (This was discussed in the "future work" section of our DLS paper.) Basically my question is: Would OMeta loose something by being a generator > instead of a "programming lang with a PEG control structure"? > It's perfectly reasonable to think of the OMeta compiler as a "pattern-matcher generator" (but not a "parser generator", since OMeta can do a lot more than just parsing). So I guess the answer is "no". It seems to me that the main benefit to OMeta's choice is conceptual > simplicity; a parser writer need not distinguish between two different > levels (in Rockit you extend the set of commands with normal Ruby code but > then write your grammar using the existing commands) but can use a single > formalism. Or are there other benefits? > What do you mean by "OMeta's choice"? Are you still talking about productions with arguments? (I'm guessing you're not, since you're talking about "two different levels".) In general, I think that the benefits of using OMeta as a language prototyping tool are: (1) conceptual simplicity, (2) less things to learn (don't worry about lex, yacc, visitors; OMeta can do all of that stuff in a natural and straight-forward way), and (3) you can use features like inheritance and parameterized productions in every part of your implementation. I hope this helps. Cheers, (Not-yet-Dr.) Alex > Thanks for any input and best regards, > > /Robert Feldt > -- > PhD, Assistant Professor in Software Engineering > Blekinge Inst. of Technology, School of Engineering (APS), SE-372 25 > Ronneby, Sweden > Personal web: http://drfeldt.googlepages.com/ > Research group web: http://www.bth.se/tek/serl/
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
