On Jun 21, 2011, at 4:02 PM, Malcolm Wallace wrote:

On 21 Jun 2011, at 20:53, Elliot Stern wrote:

...

A tuple is basically an anonymous product type. It's convenient to not have to spend the time making a named product type, because product types are so obviously useful.

Is there any reason why Haskell doesn't have anonymous sum types? If there isn't some theoretical problem, is there any practical reason why they haven't been implemented?

The Either type is the nearest Haskell comes to having anonymous sum types.

If you are bothered because Either has a name and constructors, it does not take long before you realise that (,) has a name and a constructor too.

Yes, Either is to sum types what (,) is to product types. The difference is that there is no "anonymous" sum type equivalent to (,,) and (,,,) and (,,,,) and so on, which I think is what the original question is getting at. Indeed, I sometimes wish I could write something like (straw-man syntax): foo :: (Int | Bool | String | Double) -> Int foo x = case x of 1stOf4 i -> i + 7 2ndOf4 b -> if b then 1 else 0 3rdOf4 s -> length s 4thOf4 d -> floor d bar :: Int bar = foo (2ndOf4 True) and have that work for any size of sum type. But I can't. Cheers, -Matt

On Tue, Jun 21, 2011 at 3:36 PM, Matthew Steele wrote:

On Jun 21, 2011, at 4:02 PM, Malcolm Wallace wrote:

...

On 21 Jun 2011, at 20:53, Elliot Stern wrote:

...

A tuple is basically an anonymous product type.  It's convenient to not have to spend the time making a named product type, because product types are so obviously useful.

Is there any reason why Haskell doesn't have anonymous sum types?  If there isn't some theoretical problem, is there any practical reason why they haven't been implemented?

The Either type is the nearest Haskell comes to having anonymous sum types.

If you are bothered because Either has a name and constructors, it does not take long before you realise that (,) has a name and a constructor too.

Yes, Either is to sum types what (,) is to product types.  The difference is that there is no "anonymous" sum type equivalent to (,,) and (,,,) and (,,,,) and so on, which I think is what the original question is getting at.  Indeed, I sometimes wish I could write something like (straw-man syntax):

 foo :: (Int | Bool | String | Double) -> Int  foo x =    case x of      1stOf4 i -> i + 7      2ndOf4 b -> if b then 1 else 0      3rdOf4 s -> length s      4thOf4 d -> floor d  bar :: Int  bar = foo (2ndOf4 True)

and have that work for any size of sum type.  But I can't.

Why not just do what we do for tuples? Define a bunch of generic types up front: data Choice2 a b = OneOf2 a | TwoOf2 b data Choice3 a b c = OneOf3 a | TwoOf3 b | ThreeOf3 c . . . Then you wouldn't need any special compiler support, and you can release it on its own library on Hackage. I don't think I would use it, be to each their own!

Cheers, -Matt

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, Jun 21, 2011 at 1:36 PM, Matthew Steele wrote:

Yes, Either is to sum types what (,) is to product types. The difference is that there is no "anonymous" sum type equivalent to (,,) and (,,,) and (,,,,) and so on, which I think is what the original question is getting at. Indeed, I sometimes wish I could write something like (straw-man syntax):

foo :: (Int | Bool | String | Double) -> Int foo x = case x of 1stOf4 i -> i + 7 2ndOf4 b -> if b then 1 else 0 3rdOf4 s -> length s 4thOf4 d -> floor d bar :: Int bar = foo (2ndOf4 True)

and have that work for any size of sum type. But I can't.

Haskell operators are pretty flexible. You can get something really close without much effort. Consider: import Data.Either type (:|:) a b = Either a b (???) = either foo :: (Int :|: Bool :|: String :|: Double) -> Int foo = \ i -> i + 7 ??? \ b -> if b then 1 else 0 ??? \ s -> length s ??? \ d -> floor d

Arlen Cuss writes:

...

import Data.Either type (:|:) a b = Either a b (???) = either

foo :: (Int :|: Bool :|: String :|: Double) -> Int foo = \ i -> i + 7 ??? \ b -> if b then 1 else 0 ??? \ s -> length s ??? \ d -> floor d

INFIX TYPE OPERATORS!!??!

O_________________________________________O

Yep. http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/data-type-extensions.... -- lelf

On Jun 21, 4:15 pm, Alexander Solla wrote:

The problem is that a sum type must "name" the different types, or else it can't give access to them.  How is a function supposed to know if a value

blah :: A :+: B

is an A or a B?  It seems possible that it could figure it out, but that problem is undecidable in general.

Why can't you use pattern matching? We'd probably want to change the syntax a little, to tell Haskell that we want to use an anonymous sum. Something like: foo :: Bar :+: Baz -> Quux foo <Bar bar> = ... foo <Baz baz> = ... Would finding the type signature of foo be undecidable?

On Jun 21, 4:57 pm, Alexey Khudyakov wrote:

Types may be same.

oops :: Int :+: Int -> Int oops <Int i> = mmm which one?

If you were to have your anonymous sum types be a union instead of the disjoint union, then you could say that A :+: A has no meaning. That's what I was originally thinking of when I suggested that syntax. However, as was pointed out to me by David Sankel, disjoint unions are more powerful than regular unions. Since that's the case, Matthew Steele's suggested syntax makes more sense. It means that you need to remember the order of your arguments, but you need to do that with tuples, anyway.

On Tue, Jun 21, 2011 at 2:24 PM, pipoca wrote:

On Jun 21, 4:57 pm, Alexey Khudyakov wrote:

...

Types may be same.

oops :: Int :+: Int -> Int oops <Int i> = mmm which one?

If you were to have your anonymous sum types be a union instead of the disjoint union, then you could say that A :+: A has no meaning.

That sort of union would not be parametric, and would play havoc with generic programming. E.g. consider taking a list [(t,Int)] and [(t,a)] and generating a list of [(t,Int :+: a)], then processing this with a function of the form Int -> Bool.