#5144: Pattern synonyms
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonmar):
I've been thinking about how to design this extension to get the most
bang for the buck. Here's a slightly different proposal that I think
has some nice properties, and is still quite simple.
Pattern synonyms define new '''varids''' rather than '''conids'''.
For example, we could add this to `Data.Sequence`:
{{{
pattern empty = t | Nothing2 <- viewLTree t
pattern x <| xs = t | Just (x,xs) <- viewLTree t
pattern xs |> x = t | Just (x,xs) <- viewRTree t
}}}
which would subsume all the existing `ViewL`/`ViewR` stuff. Note that
the pattern right hand side may include a pattern guard (or view
patterns).
The big win here is that you can use the same varid as an existing
function function, so you get to define both constructors and
destructors, and they look identical. Furthermore you get pattern
matching (view-style) on abstract types.
You could do this with conids instead of varids if there was also some
way to define the expression form - that's the tricky part, which is
why I thought varids would be a better choice. Also varid patterns
give you a clue that something magic is going on, but in a nicer way
than view patterns.
Not many changes to Haddock etc. would be required (I think if we used
conids it would be a bit trickier: should they be indistinguishable
from ordinary datatypes or not?)
A design question is whether the pattern should be required to have
the same type as the function, if both exist. There could be all
sorts of hairy issues there. If they aren't the same, can you give a
type signature to a pattern?
This extension to pattern synonyms covers all the use cases of view
patterns in which there is a single identifier to the left of the
arrow (which is about 90% of the examples in ViewPatterns). Perhaps
there's some way to extend this to allow passing arguments from the
pattern site too... it's just a syntax question (but a gnarly one). So
while with view
patterns you can define an n+k pattern, with pattern synonyms it has
to be restricted to a particular `k`:
{{{
pattern oneplus n = m | m > 0, let n = m - 1
f 0 = ...
f (oneplus n) = ...
}}}
I do think for the cases where pattern synonyms apply, the syntax is
much nicer than view patterns. In particular, there's no need for
intermediate Maybes or tuples, which the view pattern proposal
suggests to make implicit.
Another one:
{{{
pattern x `and` y = it | x <- it, y <- it
}}}
(this was called `both` in ViewPatterns).
In conclusion: I'm not sure whether this is the right thing, but from
certain angles it looks very attractive. Thoughts?
--
Ticket URL: <
http://hackage.haskell.org/trac/ghc/ticket/5144#comment:2>
GHC <
http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Locked
