Constraints on definition of `length` should be strengthened

[Nathan Bouscal]

- The message I was directly responding to included the phrases 'instances
we think a "better Haskell" wouldn't have' and 'doing what we don't want
before someone else has a chance to'. That's what I was responding to when
I said that the instances are useful.
- You're trying to establish an analogy between these tuple instances and
non-law-abiding instances, but that analogy really doesn't work. These are
the only law-abiding instances that the types can possibly have. When I
claim something is a Monad, I'm saying that if the compiler knew how to
take a proof, I'd be able to provide one. When you claim tuples are
unbiased, there is no analogous statement. You can't say that you'd be able
to provide a proof that tuples are unbiased, because they *aren't* unbiased.
- A lot of these arguments are taking the form "let's have unbiased
tuples", but the actual impact of just removing the instances wouldn't be
unbiased tuples, it would be a crippled biased tuple. Getting rid of the
instances wouldn't make tuples any less biased, it would just take away
useful functionality. Suggestions like Vladislav's of implementing an
actual unbiased tuple are more reasonable (though as pointed out, they'd
break *tons* of code, so still not that reasonable).

On Sat, Apr 8, 2017 at 4:28 PM, Ben Franksen <ben.franksen at online.de> wrote:

> Am 07.04.2017 um 00:48 schrieb Nathan Bouscal:
> > It *is* actually a useful instance and it is used in practice. It's not
> > that better Haskell wouldn't have an biased pair type with these
> instances,
> > it's that it would *also* have an unbiased one with the instances that
> such
> > a type could support.
>
> Nobody (I think) claimed that the biased type isn't useful. We merely
> discuss whether it would not be more useful to define new types for that
> with names that convey the intent, and leave (,) and Either unbiased as
> their name (and special notation) suggests.
>
> > The issue seems to be that people don't like the
> > biased type having special syntax that wrongly gives an unknowing reader
> > the impression that the type is unbiased.
>
> This is not the only reason, see above.
>
> > This is a reasonable position,
> > but getting rid of the tuple instances isn't a reasonable way to act on
> > that position: 1) they're going to be defined anyway,
>
> Would you say the same for non-law-abiding instances for, say, class Monad?
>
> > but also 2) it's not
> > helpful to just pretend the type is unbiased when it isn't.
>
> We are used to pretend a lot in Haskell. We cannot capture all
> properties in types, but we expect them to hold nevertheless. Are you
> saying that this is bad because, well someone is going to come and
> define a Monad instance that doesn't obey the laws anyway, so let's not
> pretend the Monad laws hold?
>
> > It would be
> > coherent to argue for the removal of the special tuple syntax (though
> > coherent doesn't mean reasonable; this would break everything), but it's
> > not coherent to argue for crippling tuples so we can pretend they're
> > something they aren't.
>
> Pretending that a thing is actually something other than it really is is
> the whole idea of high level languages. All data and code are just bits
> in the end. You can enforce certain re-interpretations of these bits
> using a type system. But what matters is that we intend a Char to be a
> character and consciously avoid asking "what it really is" i.e. how it
> is represented.
>
> Cheers
> Ben
>
> _______________________________________________
> 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/20170408/baa66480/attachment.html>