Constraints on definition of `length` should be strengthened

[Nathan Bouscal]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170403/fd5c3f4b/attachment.html>