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 |
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: 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 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 |
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: Exactly.
Yep. :-) BTW, I find it remarkable that of those who defend these instances, few 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 |
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. In http://hackage.haskell.org/package/semigroupoid-extras-5/docs/Data-Semifunctor.html Bi (,) and Bi Either provide these semantics today. 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? _______________________________________________ Libraries mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |