<p dir="ltr">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.</p>
<p dir="ltr">data HList :: [*] -> * where<br>
  HNil :: HList '[]<br>
  HCons :: a -> HList as -> HList (a ': as)</p>
<p dir="ltr">data PatternResult :: ([*] -> Constraint) -> * where<br>
  PatternResult :: provides ts => HList ts -> PatternResult provides</p>
<p dir="ltr">type Matcher requires provides = forall x . requires x => x -> PatternResult provides</p>
<p dir="ltr">The smart constructor side of a pattern synonym is much, much simpler! It's just a regular old Haskell value! The only special bit is that it's treated, syntactically, as a constructor. There's simply nothing else worth saying about it, so the less said the better.</p>
<div class="gmail_quote">On Apr 20, 2016 1:48 PM, "David Feuer" <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p>
<div class="gmail_quote">On Apr 20, 2016 1:41 PM, "Carter Schonwald" <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Shouldn't the design simply be both directions are the dual of the other, and pure in some sense ?<div><span></span><br><br>On Wednesday, April 20, 2016, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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 be free to do some things that "don't make sense", and that doesn't bother me in the least.</p>
<div class="gmail_quote">On Apr 20, 2016 1:27 PM, "Carter Schonwald" <<a>carter.schonwald@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Would that duality be related to the given vs wanted constraints ?<span></span><br><br>On Wednesday, April 20, 2016, David Feuer <<a>david.feuer@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As far as I can tell from the 7.10 documentation, it's impossible to<br>
make a bidirectional pattern synonym used as a constructor have a<br>
different type signature than when used as a pattern. Has this been<br>
improved in 8.0? I really want something like<br>
<br>
class FastCons x xs | xs -> x where<br>
  fcons :: x -> xs -> xs<br>
class FastViewL x xs | xs -> x where<br>
  fviewl :: xs -> ViewL x xs<br>
<br>
pattern x :<| xs <- (fviewl -> ConsL x xs) where<br>
  x :<| xs = fcons x xs<br>
<br>
This would allow users to learn just *one* name, :<|, that they can<br>
use for sequences that are consable or viewable even if they may not<br>
be the other.<br>
<br>
If this is not yet possible, then I think the most intuitive approach<br>
is to sever the notions of "pattern synonym" and "smart constructor".<br>
So I'd write<br>
<br>
pattern x :<| xs <- (fviewl -> ConsL x xs)<br>
constructor (:<|) = fcons<br>
<br>
The current syntax could easily be desugared to produce *both* a<br>
pattern synonym and a smart constructor in the bidirectional case.<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a>ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</blockquote></div>
</blockquote>
</div></blockquote></div>
</blockquote></div>