Think about it this way. The matching aspect of a pattern synonym is
basically about defining a function to a somewhat weird type, except of
course optimized and maybe a bit more general.
data HList :: [*] -> * where
HNil :: HList '[]
HCons :: a -> HList as -> HList (a ': as)
data
I don't know what that means. There's no way to enforce duality at the term
level. Enforcing it at the type level prevents me from doing what I want
and serves no apparent purpose. Remember that pattern synonyms are all
about providing nice syntax, not adding essential expressiveness.
On Apr 20,
Shouldn't the design simply be both directions are the dual of the other,
and pure in some sense ?
On Wednesday, April 20, 2016, David Feuer wrote:
> To some degree, it probably could be. But I believe that imposing any
> substantial relationship between the smart
To some degree, it probably could be. But I believe that imposing any
substantial relationship between the smart constructor and the pattern
synonym is likely to fall squarely into the category of things that are
subtle, hard, and almost completely useless. In the arrangement I
suggested, people
Would that duality be related to the given vs wanted constraints ?
On Wednesday, April 20, 2016, David Feuer wrote:
> As far as I can tell from the 7.10 documentation, it's impossible to
> make a bidirectional pattern synonym used as a constructor have a
> different type
As far as I can tell from the 7.10 documentation, it's impossible to
make a bidirectional pattern synonym used as a constructor have a
different type signature than when used as a pattern. Has this been
improved in 8.0? I really want something like
class FastCons x xs | xs -> x where
fcons :: x