> 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) > > > > Yes, this seems like a better solution from a readability-perspective. > Being trained as a Haskell programmer (I did my undergrad at Chalmers univ > where the first programming course, the first day, starts introducing lazy > eval and pattern matching in Haskell :) ) I feel right at home. I'm not sure > you really want this power in your matching spec language though, but maybe > I'll see the power when/if implementing it... ;) > > I would imagine you see lots of use for this when transforming trees? I > had a similar thing in an older version of Rockit but the pattern matching > was done external to the matching/parsing framework itself. This could unify > things; nice. >
Right... this kind of pattern matching makes languages like ML and Haskell really good for writing tree transformations. And since OMeta is all about transformations, I've always thought this was a worthwhile feature. Especially given that it's so cheap in terms of conceptual overhead and implementation effort. Have you looked at Katahdin? He made some interesting choices there to > support different types of recursion and precedence even while maintaining a > (mostly; he goes for longest-match "or" instead of prioritized choice) PEG > base. I haven't read your "supporting recursion in peg" paper yet but there > might be connections to his choices. > I have looked at Katahdin, and it does look like an interesting project. The way he handles left-recursive rules is similar to the approach described in our PEPM paper, although ours does not rely on explicit annotations on left-recursive productions. The whole precedence thing (which is why he uses longest-match choice instead of ordered choice) I'm not so happy with, but I guess it's a matter of taste. (That, and the fact that using cascading productions to implement operator precedence seems to be more compatible with OMeta's notion of grammar inheritance.) Cheers, Alex > > Regards, > > Robert > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
