Malcolm Wallace wrote:

Conor McBride writes:

...

P x y z = C x (y, [z])

Isn't this idea very similar to views, and pattern-guards?

Clearly related, but rather cheaper. I don't want to make remarks, positive or negative about either of those proposals at this juncture. I see pattern synonyms, like type synonyms, as a convenient abbreviation mechanism in a part of the language where verbosity is currently compulsory.

For instance, you could rewrite your example thus:

data EffectView x = Bang | Bing x | Dull x

view :: MyEffect x -> EffectView x view (Comp Nothing) = Bang view (Comp (Just (Prod (Any True), Id x))) = Bing x view (Comp (Just (Prod (Any False), Id x))) = Dull x

my_function e | Bang <- view effect = ... | Bing x <- view effect = ... x ... | Dull x <- view effect = ... x ...

You forgot to define the term behaviour also. Pattern synonyms may be used to construct as well as to match values. Of course, I could also write weiv :: EffectView x -> MyEffect x weiv Bang = ... weiv (Bing x) = ... weiv (Dull x) = ... or I could just add them as definitions with lower-case initials. The pattern synonym gives me both at once, and their relationship. Moreover, I don't have to either (a) cover the entire type with pattern synonyms or (b) write a partial view; I just abbreviate whenever I find it convenient. More moreover, your way, the need to interpolate the view encoder forces me to do my matching in a guard, rather than an argument pattern, hence the need to say 'view effect' three times, or however many it happens to be, and some irritation in mixing matching on MyEffect x with matching on other arguments. But perhaps constructing explicit embedding-projection pairs is a better solution than an abbreviation mechanism, for most people's needs. All the best Conor This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

On 2/16/06, Henrik Nilsson wrote:

Conor and I discussed this over lunch.

Specifically, we talked about whether the right hand side of a pattern synonym would be any Haskell pattern (including "_", "~", possibly "!"), or restricted to the intersection between the patterns and terms, as Conor propose that pattern synonyms also be used for construction.

By adopting some simple conventions, like replacing "_" by "undefined" when a synonym is used as a term for construction, it is clear that one can be a bit more liberal than a strict intersection between the pattern and current expression syntax.

I would speak against this. I like the idea of pattern synonyms, but I think they should be just that - pattern synonyms, and not try to mix in expressions as well. With the current (H98) pattern situation, it *might* be possible to tweak things so that all patterns have an expressional meaning (e.g. "_" as "undefined"), but 1) it would be fairly construed in many cases, and 2) it would complicate making extensions to the pattern matching facility. (Shameless plug:) In particular I'm thinking about our extension HaRP [1] that adds regular expressions to pattern matching over lists. The ability to define pattern synonyms would be really useful in conjunction with HaRP, but if those patterns are required to also have an expressional meaning it would make things fairly complicated, not to say impossible. Instead I would like to propose an extension to the proposed extension in another direction: Adding in (pattern) guards. Consider patterns like IsSpace x = x | isSpace x Last x = xs | x <- last xs This would in particular go well together with HaRP, where you in some cases need guards to be inlined, e.g. words [ (IsSpace _)*!, (/ xs@:(_*), (IsSpace _)*! /)* ] = xs Btw, why not consider adding regular patterns a la HaRP to Haskell'? :-) (Disclaimer: I'm not really serious, like Lennart I don't really feel that any of this has any place in Haskell'. But as for the future beyond that, I am serious.) [1] http://www.cs.chalmers.se/~d00nibro/harp

Most of this discussion on patterns (except for views) seems too much focused on concrete data types. (regexps for lists: what a horrible thought :-) This is just the thing to avoid in software design. (Don't expose implementation details, use interfaces etc.)

There's nothing in HaRP that would not work seamlessly with any sequential datatype through an interface of destructors, and clearly that's the Right (TM) way to go. The current implementation is just proof of concept. :-) IMO your comment only further speaks for my proposal to add guards to pattern synonyms. With an interface of destructors, you could define patterns that don't say anything about the underlying implementation, e.g. Head x = xs | x <- head xs where the head function comes from some interface for sequences. This is not something that can be done currently, nor with the initial proposal for pattern synonyms. /Niklas