On Dec 11, 2007 11:45 PM, Alessandro Warth <[EMAIL PROTECTED]> wrote:
> Hello Robert, > Hi Allessandro, 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. 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".) > 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. > > 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, Robert
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
