Constraints on definition of `length` should be strengthened

[Sven Panne]

2017-04-03 18:38 GMT+02:00 Henning Thielemann <lemming at henning-thielemann.de
>:

>
> On Mon, 3 Apr 2017, David Feuer wrote:
>
> That leaves a few trouble spots:
>>
>> 1. There are types that some people think shouldn't have
>> Functor/Foldable/Traversable instances at all, or that some people would
>> like to have Functor and maybe even Traversable instances for without
>> wanting Foldable instances. The latter is impossible because of a
>> superclass constraint. One essential issue here seems to be one of
>> perspective: is Foo x y a container of ys, decorated with xs, or is it a
>> container of xs and ys? Different people tend to think about this
>> differently, and thus form different intuitions.
>>
>
> I don't know if anyone has a problem with interpreting a custom data type
> Foo x y as a container of ys decorated with xs - if it is defined for that
> purpose. Discussion arose solely about the cases Foo = (,), Foo = (,,) x
> and so on.


Of course such an interpretation is possible, but let's remember Abelson's
famous quote:

   "Programs must be written for people to read, and only incidentally for
machines to execute."

When you show somebody a pair and ask "What is this?", how many people do
you *seriously* expect to say "Oh, yeah, I've seen that: It's a value on
the right decorated by another one on the left!" compared to people telling
you something about e.g. cartesian products (which are totally symmetric
with no bias to the right or left)? The point is: Using a pair for a
decorated one-element container is completely miscommunicating your intent,
even if you find a sensible mathematical interpretation for it. All the
programs from http://www.ioccc.org/ have a sensible mathematical
interpretation, too, but that doesn't mean I want to see them outside of
that contest. ;-)


> E.g. I actually proposed to define a custom data type like Decorated x y
> instead of (x,y) in case you want to have a Foldable instance.


*This* is communicating you intent IHMO, and I doubt you need more types
for different arities: If you e.g. want to have 3 values for decoration,
just use a triple (or something isomorphic) with Decorated. This is much
clearer than having a family of Decorated, Decorated2, Decorated3, ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170403/af79c1e5/attachment-0001.html>