Constraints on definition of `length` should be strengthened

[Vladislav Zavialov]

There's a way to get unbiased products in Haskell. The trick is to
make their kind [Type] -> Type:

data family Product (xs :: [Type])

data instance Product '[] = Unit
data instance Product '[a] = Id a
data instance Product '[a,b] = Pair a b
data instance Product '[a,b,c] = Triple a b c
...

We could make (a,b) syntactic sugar for Product '[a,b] at type level
and for Pair at term level - this would invalidate all asymmetric
instances. Unfortunately, this is would break an immense amount of
code and violate the Haskell standard.

(Another variation is to define Product inductively as a GADT with
constructors Cons and Nil, but the result would be a HList that has a
different memory representation than tuples).

On Tue, Apr 4, 2017 at 12:14 AM, Nathan Bouscal <nbouscal at gmail.com> wrote:
>
>
> On Mon, Apr 3, 2017 at 1:48 PM, Sven Panne <svenpanne at gmail.com> wrote:
>>
>> 2017-04-03 22:29 GMT+02:00 Nathan Bouscal <nbouscal at gmail.com>:
>>>
>>> I expect most people probably agree that it'd be nice to have tuples be
>>> an unbiased cartesian product, but the actual fact of the matter is that
>>> tuples as they exist in Haskell are biased.
>>
>>
>> Tuples *are* unbiased, the bias is just an artifact of seeing them as a
>> curried function, where the positions are "eaten" from left to right. Again,
>> this mathematically correct, but more often than not the main intent of
>> using a tuple-
>>
>
>
> … no, they're not. What other type of correct is there than mathematically
> correct? "Zero isn't an integer, that's just an artifact of *seeing* it as
> an integer."
>
>
>>>
>>> We can't just ignore that and pretend they're unbiased.
>>
>>
>> We *can* ignore that, just use Henning's Decorated for an isomorphic
>> variant.
>>
>>>
>>> It definitely sucks that the answer people would naively give to "what is
>>> a tuple in Haskell" is not the correct answer, but we're stuck in that
>>> situation.
>>
>>
>> See above, we are not stuck: We *can* get back normal people's intuition
>> and Haskell's semantics back in line by removing the tuple instances and
>> adding something like Decorated. It is just a matter of priorities: This
>> will temporarily damage the Haskell ecosystem a bit, but in the long run it
>> will be the nicer, more explicit, more intuitive way.
>>
>
>
> You can't get tuples to behave like they're unbiased. You can try to hide
> the fact that they're biased by getting rid of the only possible instances
> they can support, but that doesn't magically make them unbiased. It sounds
> like you just want to rename tuples to Decorated. Maybe that's a good idea,
> but call it what it is.
>
>>>
>>> The question is how to make the best of it.
>>
>>
>> If the tuple instances are removed and Decorated is added, things are easy
>> to fix: The compiler will tell you exactly the places where you were too
>> lazy to define and use a custom data type, and the fix is mechanical. The
>> current situation is quite the opposite: People silently get totally
>> unexpected behavior.
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>