Re: Constraints on definition of `length` should be strengthened
On Tue Apr 4 06:50:55 UTC 2017, Sven Panne wrote:
2017-04-04 8:15 GMT+02:00 Vladislav Zavialov:
Tuples are unbiased cartesian products, full stop.
This statement is not correct.
According to probably all the math books in the world, the statement is correct, at least if we want to see tuples as cartesian products. ..
Sven, I have a lot of sympathy with the digruntlement about Foldable `length` over tuples. But if you're going to start appealing to math, you'd better get your math correct. Whether or not tuples are unbiased, even wikipedia will tell you they're not commutative. 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 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. Then we can talk about our currying/kind system. Note that there's been an `instance Foldable Maybe` for ever, and `toList` applied to that returns a 0-or-1 length list.
Look at their kind:
:k (,) (,) :: * -> * -> *
The same currying business is going on here. [...]
That's an artifact of our kind system, not a consequence of the usual definition of cartesian products.
AntC
Am 08.04.2017 um 04:03 schrieb Anthony Clayden:
On Tue Apr 4 06:50:55 UTC 2017, Sven Panne wrote:
2017-04-04 8:15 GMT+02:00 Vladislav Zavialov:
Tuples are unbiased cartesian products, full stop.
This statement is not correct.
According to probably all the math books in the world, the statement is correct, at least if we want to see tuples as cartesian products. ..
Sven, I have a lot of sympathy with the digruntlement about Foldable `length` over tuples. But if you're going to start appealing to math, you'd better get your math correct.
Whether or not tuples are unbiased, even wikipedia will tell you they're not commutative.
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.
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. 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? It has been stated that "obviously" length (1,2) must be 1 ("what else could it be?"). This suggests that there is a law for length that makes this obvious and its ommision in the docs was just an oversight. Cheers Ben
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.
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...
Sven Panne
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 Jon.Fairbairn@cl.cam.ac.uk
participants (4)
-
Anthony Clayden -
Ben Franksen -
Jon Fairbairn -
Sven Panne