Conversation

It could be two functors, it's just very unclear which. 'Right' was chosen due to silly mnemonic reasons for error handling. An hypothetical lang might allow you to bind either path with equal ease, but it would still be of use to have a type that is marked for passing errors.
2
There's no "silly mnemonics" involved at all, and no arbitrary choices. Left a because a is on the left in Either a b, Right b as it's on the right.
1
I think here you're confusing one specific use case with a simple, general type. It's "monads are not burritos, monads are not containers, ..." all over again.
1
This is kind of the problem with Haskell's nominal datatypes, canonical typeclass instances, and biased type and value abstraction in general. Pros and cons. Personally I'm a fan of just going with it an giving things meaningful names in lieu of anonymous unions.
2
1
I feel like there is work still to be done here - how to maintain the lovely compositional feeling of currying while also eliminating the need to settle on arbitrary biasing - in data structures, arguments, and instances. A non-trivial problem to solve.
1
1
I think you'd want something like row polymorphism for type parameters... has anyone actually implemented or studied that before?
1
1
Well yeah, I was assuming you already "have" row polymorphism for term-level function args in the language, and the hard question is how to do it for type args... and in a dependently typed language (or 1ML) there's presumably only 1 question, as hard as the second one.
1
1
Show replies