This is really to see such a discussion here. Do not take it
privately (at least this is my wish).
stef
On 11 déc. 07, at 23:45, Alessandro Warth wrote:
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
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
