Why are all recursive pattern synonyms rejected?

214 views Asked by At
{-# LANGUAGE PatternSynonyms, ViewPatterns #-}

data Quun = Foo | Bar | Oink Quun

fooey :: Quun -> Bool
fooey Foo = True
fooey (Oink Yum) = True
fooey _ = False

pattern Yum <- (fooey -> True)

This doesn't compile (at least in GHC-7.10.2)

/tmp/wtmpf-file10227.hs:1:1:
    Recursive pattern synonym definition with following bindings:
      foo (defined at /tmp/wtmpf-file10227.hs:(6,1)-(8,13))
      Yum (defined at /tmp/wtmpf-file10227.hs:10:1-28)

Sure, for simple directly self-referring patterns this would make sense. But is there some fundamental reason why even a view-pattern mediated layout as above isn't possible? I can't find this convincing; after all it's possible to inline the view pattern and get a perfectly harmless (well... at least, allowed) definition:

fooey :: Quun -> Bool
fooey Foo = True
fooey (Oink (fooey -> True)) = True
fooey _ = False

pattern Yum <- (fooey -> True)

So, are such synonyms just not available yet for technical reasons, and will we get them in the future?

1

There are 1 answers

2
Reid Barton On

Some recursive patterns are problematic, like

f :: [()] -> Bool
f L = True
f _ = False

pattern L <- () : L

What is this supposed to desugar to?

Patterns aren't first-class values. They are just replaced with their definitions where they appear. For such a language, recursive definitions are not generally sensible.