> 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.) > > > > Ok, I see the reason now. Have you found this feature (pattern matching on > their arguments) useful/powerful in practice? It seems to me it might make > reading the grammar/match-spec more difficult since the right-hand-side then > would have two different types of elements. >
You're right, it would be bad to have patterns for arguments and the input stream on the right hand side. That's why the current implementation lets you write argument patterns on the left hand side. Here's a little example from OMeta/JS <http://www.cs.ucla.edu/%7Eawarth/ometa/ometa-js/>: " ML-style pattern matching " ometa Fact { fact 0 => [1]; fact :n ::= <fact (n - 1)>:m => [n * m]. }. Fact match: 5 with: #fact (the :n pattern is shorthand for <anything>:n) 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".) > > > > I'm not sure. :) I think I was trying to understand the differences > between the OMeta methods with names starting with "_" and the derived ones > in the Javascript implementation. > If you're looking at the source code of OMeta/JS (more specifically, in ometa-base.js<http://www.cs.ucla.edu/%7Eawarth/ometa/ometa-js/ometa-base.js>), the methods whose names start with an underscore (e.g., _or, _not, _many) are not productions; they are more like combinators in a parser combinator library. The other methods (e.g., anything, char, spaces) are productions, so you can use them directly (in pointy brackets) in an OMeta grammar. 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. > > > > It does, thanks, > Great! Cheers, Alex > > Robert > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
