<div dir="auto">Vladislav, I wonder if you might propose a language extension to use tuple syntax the way you describe. Such an extension would allow people to tinker with this idea without making the community commit to such a change.<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Apr 4, 2017 5:25 AM, "Vladislav Zavialov" <<a href="mailto:vlad.z.4096@gmail.com">vlad.z.4096@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Tue, Apr 4, 2017 at 11:33 AM, Henrik Nilsson<br>
<<a href="mailto:Henrik.Nilsson@nottingham.ac.uk">Henrik.Nilsson@nottingham.ac.<wbr>uk</a>> wrote:<br>
><br>
> For the sake of argument, suppose some mechanism were adopted to<br>
> mitigate the bias implied by the (inevitable) ordering of arguments<br>
> to to type constructors. For tuples, we might imagine some kind<br>
> of notation inspired by operator sections as a first step, making the<br>
> following instance declaration possible:<br>
><br>
>     instance Functor (,b) where<br>
>         ...<br>
><br>
> Would tuples then still be biased in the above sense, and if<br>
> so why?<br>
><br>
<br>
</div>No, tuples wouldn't be biased if (a,) and (,b) could behave the same,<br>
i.e. 'f x' could be instantiated as both '(a,x)' and '(x,b)'. However,<br>
what you propose is not possible in Haskell and the extension is not<br>
straightforward.<br>
<br>
(1) Writing (,b) would require type-level lambda functions, as it's<br>
equivalent to writing '\a -> (a,b)'. Type-level lambdas are not<br>
straightforward at all: they conflict with the matchability<br>
(injectivity+generativity) assumption about type constructors -<br>
currently 'f a ~ g b' implies 'f ~ g' and 'a ~ b' - which is not true<br>
for arbitrary type-level functions. Removing this rule would wreak<br>
havoc on type inference. The solution seems to be to have two kinds of<br>
type-level arrows, as described in Richard Eisenberg's thesis on<br>
Dependent Haskell.<br>
<br>
(2) Even if type-level functions are added to the language, it's very<br>
likely that they will be disallowed as class parameters. Notice that<br>
classes perform pattern matching on types, and pattern matching on<br>
functions is impossible. So even if one could write '\a -> (a,b),<br>
writing Functor (\a -> (a,b)) would remain impossible.<br>
<br>
(3) Assume that somehow we managed to solve those problems. What<br>
instance do you define, Functor (a,) or Functor (,b)? Perhaps neither?<br>
Or maybe Functor (\a -> (a,a)) to map over both arguments? Hard design<br>
questions, many opinions will emerge! Do those instances even overlap?<br>
- determining this requires the compiler to reason about function<br>
equalities.<br>
<br>
All in all, I see only two sensible ways to proceed: accept that<br>
tuples are biased, or make them unbiased by changing their kind from<br>
Type -> Type -> Type to something uncurried.<br>
<div class="elided-text">______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
</div></blockquote></div><br></div></div></div>