Why are all recursive template synonyms rejected?

{-# 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 does not 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) 

Of course, for straightforwardly simple, self-adjusting templates, this would make sense. But is there any fundamental reason why even a mock mediated representation, as indicated above, is not possible? I cannot find it convincing; after all, itโ€™s possible to embed a presentation template and get a completely harmless (well ... at least resolved) definition:

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

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

+5
source share
1 answer

Some recursive patterns are problematic, for example

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

What does this apply to refuse?

Patterns are not first class values. They are simply replaced by their definitions of where they appear. For such a language, recursive definitions are usually not reasonable.

+5
source

Source: https://habr.com/ru/post/1243166/


All Articles