> 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) >
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. 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. > Yeah, that makes sense. 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. Regards, Robert
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
