On Tue, Jan 11, 2005 at 10:12:06PM -0500, kahl@cas.mcmaster.ca wrote:
Tomasz Zielonka <tomasz.zielonka@gmail.com> proposed an interesting kind of ``second-order as-patterns'' that are ``safe'' from the usual problems of second-order matching by virtue of fixing (at least) the spine of the images of the second-order variables.
So it is a known idea?
This could be alleviated by making the character of the intended binding as a second-order binding more explicit by allowing as-patterns to bind against function left-hand sides, where variables occurring in patterns may be ``co-bound'' in the pattern part of the as-pattern by a SINGLE occurrence of the ``co-as'' for which I continue to use Tomasz' symbol ``@>''.
The first example would then be written:
case t of (ctx zH) @ (_, _, zH @> z) -> ctx (z + 1)
Probably I get something wrong, but couldn't we simply write it this way? case t of (ctx z) @ (_, _, z) -> ctx (z + 1) That is - completely forget about @> ? Anyway, I like your notation very much. Mine was a bit clumsy.
The first occurrence of zH is a binding occurrence, and the second occurrence is co-bound by the ``@>''. (Replacing ``@>'' with ``@'' could give rise to confusing errors, no matter which way the binding of its left argument is resolved.)
Could you give an example?
The first version of Tomasz' counterexample is treated in the same way as the first example:
case t of (ctx zH) @ (x, y, (a, zH @> Just z)) -> ctx z
The expression corresponding to the ``broken'' context then exhibits a composed context:
case t of (ctx1 vH) @ (x, y, vH @> v) -> case v of (ctx2 zH) @ (a, zH @> Just z) -> ctx1 (ctx2 z)
Nice. So we could also collapse the case expressions, nesting the second-order patterns?: case t of (ctx1 vH) @ (x, y, vH @> (ctx2 zH) @ (a, zH @> Just z)) -> ctx1 (ctx2 z)
I think that this way we have the concepts right --- how useful this feature would be is probably going to be mostly a question of programming style. For very deep pattern matching in, for example, XSLT-like applications it could probably be quite convenient.
I wonder if this idea could be nicely combined with HaRP - Haskell Regular Patterns... Thanks for your insightful and enlightening comment! Best regards, Tomasz