Constraints on definition of `length` should be strengthened

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Constraints on definition of `length` should be strengthened

Dominic Steinitz-2
I am not sure what to make of the “documentation” to which you refer. For example, a type Tensor seems to be defined. Now you can tensor lots of things with some algebraic structure but most commonly vector fields and modules (modules in the mathematical sense that is). The type Tensor seems to have no relation to these and there is no prose giving an indication of the author’s intent. Perhaps we should be cautious about adducing other parts of the package as evidence?

> Already done mate.
>
> https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Either
> https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Functor
>
> Note the multiple Functor instances for Either and Coproduct. e.g.
>
> - Functor * (* -> *) Either
> - Functor * * (Either a)
> etc etc
>
> On 09/04/17 10:29, Henrik Nilsson wrote:
>> And of course, if, in a hypothetical future version of Haskell
>> where we could make all possible functor instances for tuples,
>> the question becomes: which one do we pick? The answer might well
>> be "none" (in the prelude, at least).

Dominic Steinitz
[hidden email]
http://idontgetoutmuch.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Constraints on definition of `length` should be strengthened

Sven Panne-2
In reply to this post by Jon Fairbairn
2017-04-06 9:33 GMT+02:00 Jon Fairbairn <[hidden email]>:
Sven Panne <[hidden email]> writes:
[...] Although something like Error/OK would have been better than
> Left/Right, a slight majority preferred to give a bias to Either. The
> reasoning was that using "Right" for a "wrong" outcome (i.e. failure) would
> be a bit obscure, and there was already quite some code using it in the way
> we still do today. The bias is even explicitly documented in the Haddock
> docs for Data.Either for ages, so it would not be very wise to change the
> meaning here after roughly 2 decades.

I guess this means that Haskell has failed to sufficiently avoid
success. If a mistake in library design is bad enough (not
necessarily the case for Either, but arguably so), it should be
corrected even after 20 years.

Just to clarify my POV: I didn't want to criticize anything here, I just wanted to point to some previous discussion. In my POV, Either *is* intended as a biased sum type (there are tons of more or less standard libraries which use it that way), while pairs/tuples are intended as unbiased product types. Of course one can see it in the exact opposite (still consistent) way, but this wasn't the historical intention, at least that's my personal interpretation...
 
> Of course the question remains: What is the totally unbiased standard sum
> type for 2 alternatives?

What are you asking? It sounds like an invitation to bikeshed!
In general, though, types such as (,) and Either should be used
very sparingly. In many cases it would be better to define a new
type for the specific purpose.

I think we are in the same boat here, sorry if I didn't make that clear.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Constraints on definition of `length` should be strengthened

Sven Panne-2
In reply to this post by Ben Franksen
2017-04-09 2:01 GMT+02:00 Ben Franksen <[hidden email]>:
Am 08.04.2017 um 04:03 schrieb Anthony Clayden:
> [...] So to take your examples from an earlier thread,
> what do you expect Haskell to do here?:
>
>    maximum (True,2)   =>   ?
>    minimum ((3, 4),5)   => ?   -- i.e. :: ((Int, Int), Int)
>    sum (7,3.14)   =>   ?     -- i.e. :: (Int, Double)
>    product (Left $ error "Errk")   =>   ?   -- i.e. ::
> Either e Int

I (and others) think these should be type errors.

Exactly.
 

> Do you expect Foldable (a, a) to behave differently
> vs Foldable (b, a) vs Foldable ((a, a), a) vs ...?
>
> Let's get everybody agreed on that.

It would be nice if we could all agree on removing these instances.

Yep. :-) 

BTW, I find it remarkable that of those who defend these instances, few
seem to be especially interested in clarifying the OP's question: what
laws exactly do we expect for Foldable? [...]

And even if there are laws which hold for those instances, it doesn't mean that these instances should be defined. Take e.g. Bool: One can define a "Num Bool" instance which respects the usual laws (interpreting Bool basically as a "Word1", just like Word32 etc.), but we do *not* want to have this in the standard language/libraries, and for a good reason: It would make types less useful, removing a part of the usual "If it compiles, it works" safety net...

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Constraints on definition of `length` should be strengthened

Edward Kmett-2
In reply to this post by Dominic Steinitz-2
In that code, I made a more powerful version of Functor that can handle more interesting categories.

In that setting, the fact that we use 'curried' types matters quite a bit. The usual way to think of a bifunctor is as a functor from a product category, which would like like something of kind (*,*) -> *. And you can define such a beast in Haskell. The "truly unbiased" tuple some folks have been hollering for in this thread would ideally have this sort of kind. After all, then it can't be Foldable, Traversable, etc.


But in this more general setting where we can have Functors that go to other categories than just Hask, haskell's "Bifunctor", which has kind * -> * -> * is a functor that to a functor category. We can curry/uncurry the kinds involved to go back and forth between these two representations and that always works in a category that is locally small like what we can define in Haskell. 'Bi' is a form of type level uncurry.

In the hask code, Either is a functor from Hask to [Hask,Hask], where the latter is the category of functors from Hask -> Hask.
This of course, fundamentally relies on the fact that Either a being a Functor. Mutatis mutandis for (,) a being a functor.

Once you have those things you can use runNat from the package in question to move 'backwards' n arguments an:d map over any field you want, be it a bifunctor, trifunctor, whatever. Contravariant becomes a functor from an opposite category, and large numbers of classes we have just collapse away into one thing: Functor.

Bifunctor ceases to be a primitive notion and just becomes a derived fact from the existence of those two Functor instances.

I find this to be far more enlightening than a arbitrarily adopting an unbiased (,) and making the entire world adopt mutually incompatible data types. YMMV.

-Edward

On Sun, Apr 9, 2017 at 12:42 PM, <[hidden email]> wrote:
I am not sure what to make of the “documentation” to which you refer. For example, a type Tensor seems to be defined. Now you can tensor lots of things with some algebraic structure but most commonly vector fields and modules (modules in the mathematical sense that is). The type Tensor seems to have no relation to these and there is no prose giving an indication of the author’s intent. Perhaps we should be cautious about adducing other parts of the package as evidence?

> Already done mate.
>
> https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Either
> https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Functor
>
> Note the multiple Functor instances for Either and Coproduct. e.g.
>
> - Functor * (* -> *) Either
> - Functor * * (Either a)
> etc etc
>
> On 09/04/17 10:29, Henrik Nilsson wrote:
>> And of course, if, in a hypothetical future version of Haskell
>> where we could make all possible functor instances for tuples,
>> the question becomes: which one do we pick? The answer might well
>> be "none" (in the prelude, at least).

Dominic Steinitz
[hidden email]
http://idontgetoutmuch.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Constraints on definition of `length` should be strengthened

Jon Fairbairn
In reply to this post by Sven Panne-2
Sven Panne <[hidden email]> writes:

> 2017-04-06 9:33 GMT+02:00 Jon Fairbairn <[hidden email]>:
>
>> Sven Panne <[hidden email]> writes:
>> [...] Although something like Error/OK would have been better than
>> > Left/Right, a slight majority preferred to give a bias to Either. The
>> > reasoning was that using "Right" for a "wrong" outcome (i.e. failure)
>> would
>> > be a bit obscure, and there was already quite some code using it in the
>> way
>> > we still do today. The bias is even explicitly documented in the Haddock
>> > docs for Data.Either for ages, so it would not be very wise to change the
>> > meaning here after roughly 2 decades.
>>
>> I guess this means that Haskell has failed to sufficiently avoid
>> success. If a mistake in library design is bad enough (not
>> necessarily the case for Either, but arguably so), it should be
>> corrected even after 20 years.
>>
>
> Just to clarify my POV: I didn't want to criticize anything here, I just
> wanted to point to some previous discussion. In my POV, Either *is*
> intended as a biased sum type (there are tons of more or less standard
> libraries which use it that way), while pairs/tuples are intended as
> unbiased product types.

I agree with that, although somewhat reluctantly about Either.
The original intention (as I remember it, but how reliable is my
memory of meetings nearly thirty years ago?) was to pick a name
for an unbiased sum type and its constructors. We chose Either
and Left and Right (the latter two being names that had been
used in prior languages). It was then noticed that Either
provided what was needed for results that could either be a
success or an error, and Right was the obvious choice for the
success. (,) never had that: it was unbiased, apart from the
inevitable syntactic and evaluation order biases.

I would like to be able to say that (excluding questions of
evaluation order) if one systematically replaced (a,b) with
(b,a) throughout the source of a programme, it would still be
the same programme. I would also like to think that instances
provided in base were “the only sensible instance” (for some
value of sensible). This is the case for Foldable Maybe, maybe
for Either (but not for an unbiased sum) and definitely not for
(,).

--
Jón Fairbairn                                 [hidden email]


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Constraints on definition of `length` should be strengthened

Jon Fairbairn
In reply to this post by Sven Panne-2
Sven Panne <[hidden email]> writes:

> And even if there are laws which hold for those instances, it doesn't mean
> that these instances should be defined. Take e.g. Bool: One can define a
> "Num Bool" instance which respects the usual laws (interpreting Bool
> basically as a "Word1", just like Word32 etc.), but we do *not* want to
> have this in the standard language/libraries, and for a good reason: It
> would make types less useful, removing a part of the usual "If it compiles,
> it works" safety net...

Most heartily agree. Probably the programmer’s most important
use of a static type system is to catch errors at compile time.

I sit next to someone who is obliged to use scripting languages
that automatically convert things to numbers whether you want
that or not. This has several times produced hard to find bugs,
and so cost real money.

--
Jón Fairbairn                                 [hidden email]


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Constraints on definition of `length` should be strengthened

AntC
In reply to this post by Paolo Giarrusso
[Errk, somehow posted this with no Subject. Trying again.]

> On Sun Apr 9 19:24:12 UTC 2017, Sven Panne wrote:

>> 2017-04-09 2:01 GMT+02:00 Ben Franksen :

>>> Am 08.04.2017 um 04:03 schrieb Anthony Clayden:
>>> [...] So to take your examples from an earlier thread,
>>> what do you expect Haskell to do here?:
>>>
>>>    maximum (True,2)   =>   ?
>>>    minimum ((3, 4),5)   => ?   -- i.e. :: ((Int, Int),
Int)
>>>    sum (7,3.14)   =>   ?     -- i.e. :: (Int, Double)
>>>    product (Left $ error "Errk")   =>   ?   -- i.e. ::
>>>                                            Either e Int
>>
>> I (and others) think these should be type errors.
>>

> Exactly.

OK. Do y'all think there should be a `toList` method for
them?

Indeed, should there be a `toList` method available
for any data type that doesn't implement `fromList`?

Perhaps `toList` should not be a method of Foldable?

>
>>> Do you expect Foldable (a, a) to behave differently
>>> vs Foldable (b, a) vs Foldable ((a, a), a) vs ...?
>>>

>> It would be nice if we could all agree on removing these
>> instances.
>>

> Yep. :-)

>> BTW, I find it remarkable that of those who defend these
>> instances, few seem to be especially interested
>> in clarifying the OP's question: what
>> laws exactly do we expect for Foldable? [...]
>>

One of the Laws appears to be that `length` etc
behave as `length . toList`.


AntC
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
123