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 <david.fe...@gmail.com> wrote: > 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. > On Apr 20, 2016 1:27 PM, "Carter Schonwald" <carter.schonw...@gmail.com > <javascript:_e(%7B%7D,'cvml','carter.schonw...@gmail.com');>> wrote: > >> Would that duality be related to the given vs wanted constraints ? >> >> On Wednesday, April 20, 2016, David Feuer <david.fe...@gmail.com >> <javascript:_e(%7B%7D,'cvml','david.fe...@gmail.com');>> 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 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 -> xs -> xs >>> class FastViewL x xs | xs -> x where >>> fviewl :: xs -> ViewL x xs >>> >>> pattern x :<| xs <- (fviewl -> ConsL x xs) where >>> x :<| xs = fcons x xs >>> >>> This would allow users to learn just *one* name, :<|, that they can >>> use for sequences that are consable or viewable even if they may not >>> be the other. >>> >>> If this is not yet possible, then I think the most intuitive approach >>> is to sever the notions of "pattern synonym" and "smart constructor". >>> So I'd write >>> >>> pattern x :<| xs <- (fviewl -> ConsL x xs) >>> constructor (:<|) = fcons >>> >>> The current syntax could easily be desugared to produce *both* a >>> pattern synonym and a smart constructor in the bidirectional case. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
