6 ms·

All enum types look a bit sad when you're used to the full algebraic sum types + pattern matching provided by a functional language

frou_dh 13y ago
Even as someone who hasn't done any real work in such languages, your statement strikes me as viscerally true. Those features are an obvious boon for reliability.
tomp 13y ago
But sometimes you only need enums (which are, arguably, a subcategory of ADTs). E.g. playing card suits, true/false, ...
- tikhonj 13y ago
  Not just arguably--that's exactly what they are. E.g., in Haskell: data Suit = Spades | Hearts | Clubs | Diamonds deriving (Show, Eq, Bounded, Enum) this creates a type that acts exactly like an enum. With the added benefit of having a well-defined string representation and maxBound/minBound constants for free.
- gnaritas 13y ago
  True and false work fine as singleton subclasses of the abstract class Boolean; see Smalltalk.
  - tomp 13y ago
    What prevents me from making a third subclass, Undetermined? ADTs and enums are meant to prevent this.
    - gnaritas 13y ago
      > What prevents me from making a third subclass, Undetermined? Smalltalk isn't about preventing things, it's about enabling them.
dchichkov 13y ago
There is a reason why pattern matching syntactic sugar is not in python. Pattern matching is very powerful, but it is also ambiguous. And it is impossible to come up with good looking syntax, unfortunately. Ambiguous, because in the: # y = 5 # match x with: 1: "my string" 2|3: print "2,3" y: print y there is a problem. Because, really, in case of 'y' you want to be able to do both: bind variables; use already defined variables. And there is no way you can do both with clean and concise syntax. On the other hand, there is already a way to achieve the same results with if,elif,else. That's why (sadly) pattern matching is not there.
- jedi_stannis 13y ago
  This problem is also present in Haskell and it seems to work out pretty well there
  - marcosdumay 13y ago
    That. Every language solves that with a desambiguation rule. In haskell, the first matching line runs. It's no worse than the way C, Java, and family solve the if-else ambiguity, for example.
- Tobu 13y ago
  I don't get the issue. In OCaml you can do |y -> y + x If y was defined in the outside scope, the case scope just shadows it.
  - dchichkov 13y ago
    Yes, if you would only allow binding it resolves the conflict. But, if a five year old would look at the code: y = 5 match x with: 1: print '1' y: print '5' he will think it is equivalent to: y = 5 if x == 1: print '1' elif x == y: print '5' And that would not be true.
  - a-nikolaev 13y ago
    I think, he wants to match the case when x == y. You can do that too. let y = 5 in match x with 1 -> print "my string" | 2 | 3 -> print "2,3" | z when z = y -> print y
MostAwesomeDude 13y ago
Don't say "a functional language" when you mean "a member of the ML family, like OCaml or Haskell."
- chowells 13y ago
  Haskell is not an ML. Not even close.
  - spacemanaki 13y ago
    Could you elaborate on this? I would agree with "Haskell is not an ML" but I think the MLs (SML, OCaml, Mythryl, F#) are close to Haskell, and closer to Haskell than to other programming languages, certainly closer than to Scala. Haskell is lazy, pure, and has typeclasses, while MLs are strict, impure, and (sometimes, usually) have modules, ... while there might be a lot of other differences, there are a lot of similarities too, between algebraic datatypes, Hindley-Milner, pattern matching, etc...
    - michaelochurch 13y ago
      Not grandparent, but let me try. ML (Ocaml, I should say, because that's my experience) is like a functional C. As a production language, I'd recommend it highly. It has excellent garbage collection. It generates blazingly fast native code. I can't speak either way about Haskell's use in production. I'm sure that many people have made it work. I just don't know how hard it is in practice. Haskell is lazy, for one, which makes it hard to reason about performance. You can have production memory leaks that are a bitch to debug. It also has a much more powerful, but also more complex type system. Explicit functors (Ocaml) are replaced by implicit type classes, which make the language more attractive (I'll grant that) but also make it easier to hang yourself by the monads. Haskell's still a great language, and there are a million things that recommend it. However, I don't see it as occupying the same space as the ML family. The main similarity is that both use Hindley-Milner type inference, but there are a lot of differences, too. Finally, Haskell is pure (except in the IO Monad, and a couple others) while Ocaml's not. You have stateful arrays and ref cells in Ocaml, and use them all the time when you're writing high-performance production code. In Haskell, any IO is to be done "in the IO monad" (which means, "in the context of evaluating an IO a", the latter being a thunk that does IO and returns an a.)
tome 13y ago
Right, this is why I eventually, and sadly, left Python behind.
andreasvc 13y ago
Is there a technical reason why algebraic types and pattern matching are only found in functional languages, or is it an accident of history?
- tsuyoshi 13y ago
  It's sort of an accident: the inventor of ML (which SML, OCaml, and F# are descended from, and Haskell has liberally borrowed from) is the "Milner" in Hindley-Milner type checking, and algebraic types are one of the things that make Hindley-Milner useful. Anyone who's used the object-oriented part of OCaml can tell you that inheritance can mix with Hindley-Milner awkwardly... but I'm not sure that really means algebraic types and pattern matching couldn't be integrated into Java, Python, or whatever somehow. For all I know, maybe it's already on the way into C++...
  - spicyj 13y ago
    It's an integral part of Rust, which is Mozilla's new (imperative) language: http://www.rust-lang.org/ http://www.rust-lang.org/
    - habitue 13y ago
      They are also available in Ceylon (Redhat's Java successor): http://ceylon-lang.org/ http://ceylon-lang.org/
ansgri 13y ago
Don't say "a functional language" when you mean Strongly Typed languages with a specific type system. I.e. not Clojure or Scheme.
- michaelochurch 13y ago
  You can write your own pattern-matching and enum/union types in Clojure. It'll be a couple days of work, but it can be done.

frou_dh 13y ago

Even as someone who hasn't done any real work in such languages, your statement strikes me as viscerally true. Those features are an obvious boon for reliability.

tomp 13y ago

But sometimes you only need enums (which are, arguably, a subcategory of ADTs). E.g. playing card suits, true/false, ...

tikhonj 13y ago
Not just arguably--that's exactly what they are. E.g., in Haskell: data Suit = Spades | Hearts | Clubs | Diamonds deriving (Show, Eq, Bounded, Enum) this creates a type that acts exactly like an enum. With the added benefit of having a well-defined string representation and maxBound/minBound constants for free.
gnaritas 13y ago
True and false work fine as singleton subclasses of the abstract class Boolean; see Smalltalk.
- tomp 13y ago
  What prevents me from making a third subclass, Undetermined? ADTs and enums are meant to prevent this.
  - gnaritas 13y ago
    > What prevents me from making a third subclass, Undetermined? Smalltalk isn't about preventing things, it's about enabling them.

dchichkov 13y ago

There is a reason why pattern matching syntactic sugar is not in python. Pattern matching is very powerful, but it is also ambiguous. And it is impossible to come up with good looking syntax, unfortunately. Ambiguous, because in the: # y = 5 # match x with: 1: "my string" 2|3: print "2,3" y: print y there is a problem. Because, really, in case of 'y' you want to be able to do both: bind variables; use already defined variables. And there is no way you can do both with clean and concise syntax. On the other hand, there is already a way to achieve the same results with if,elif,else. That's why (sadly) pattern matching is not there.

jedi_stannis 13y ago
This problem is also present in Haskell and it seems to work out pretty well there
- marcosdumay 13y ago
  That. Every language solves that with a desambiguation rule. In haskell, the first matching line runs. It's no worse than the way C, Java, and family solve the if-else ambiguity, for example.
Tobu 13y ago
I don't get the issue. In OCaml you can do |y -> y + x If y was defined in the outside scope, the case scope just shadows it.
- dchichkov 13y ago
  Yes, if you would only allow binding it resolves the conflict. But, if a five year old would look at the code: y = 5 match x with: 1: print '1' y: print '5' he will think it is equivalent to: y = 5 if x == 1: print '1' elif x == y: print '5' And that would not be true.
- a-nikolaev 13y ago
  I think, he wants to match the case when x == y. You can do that too. let y = 5 in match x with 1 -> print "my string" | 2 | 3 -> print "2,3" | z when z = y -> print y

MostAwesomeDude 13y ago

Don't say "a functional language" when you mean "a member of the ML family, like OCaml or Haskell."

chowells 13y ago
Haskell is not an ML. Not even close.
- spacemanaki 13y ago
  Could you elaborate on this? I would agree with "Haskell is not an ML" but I think the MLs (SML, OCaml, Mythryl, F#) are close to Haskell, and closer to Haskell than to other programming languages, certainly closer than to Scala. Haskell is lazy, pure, and has typeclasses, while MLs are strict, impure, and (sometimes, usually) have modules, ... while there might be a lot of other differences, there are a lot of similarities too, between algebraic datatypes, Hindley-Milner, pattern matching, etc...
  - michaelochurch 13y ago
    Not grandparent, but let me try. ML (Ocaml, I should say, because that's my experience) is like a functional C. As a production language, I'd recommend it highly. It has excellent garbage collection. It generates blazingly fast native code. I can't speak either way about Haskell's use in production. I'm sure that many people have made it work. I just don't know how hard it is in practice. Haskell is lazy, for one, which makes it hard to reason about performance. You can have production memory leaks that are a bitch to debug. It also has a much more powerful, but also more complex type system. Explicit functors (Ocaml) are replaced by implicit type classes, which make the language more attractive (I'll grant that) but also make it easier to hang yourself by the monads. Haskell's still a great language, and there are a million things that recommend it. However, I don't see it as occupying the same space as the ML family. The main similarity is that both use Hindley-Milner type inference, but there are a lot of differences, too. Finally, Haskell is pure (except in the IO Monad, and a couple others) while Ocaml's not. You have stateful arrays and ref cells in Ocaml, and use them all the time when you're writing high-performance production code. In Haskell, any IO is to be done "in the IO monad" (which means, "in the context of evaluating an IO a", the latter being a thunk that does IO and returns an a.)

tome 13y ago

Right, this is why I eventually, and sadly, left Python behind.

andreasvc 13y ago

Is there a technical reason why algebraic types and pattern matching are only found in functional languages, or is it an accident of history?

tsuyoshi 13y ago
It's sort of an accident: the inventor of ML (which SML, OCaml, and F# are descended from, and Haskell has liberally borrowed from) is the "Milner" in Hindley-Milner type checking, and algebraic types are one of the things that make Hindley-Milner useful. Anyone who's used the object-oriented part of OCaml can tell you that inheritance can mix with Hindley-Milner awkwardly... but I'm not sure that really means algebraic types and pattern matching couldn't be integrated into Java, Python, or whatever somehow. For all I know, maybe it's already on the way into C++...
- spicyj 13y ago
  It's an integral part of Rust, which is Mozilla's new (imperative) language: http://www.rust-lang.org/ http://www.rust-lang.org/
  - habitue 13y ago
    They are also available in Ceylon (Redhat's Java successor): http://ceylon-lang.org/ http://ceylon-lang.org/

ansgri 13y ago

Don't say "a functional language" when you mean Strongly Typed languages with a specific type system. I.e. not Clojure or Scheme.

michaelochurch 13y ago
You can write your own pattern-matching and enum/union types in Clojure. It'll be a couple days of work, but it can be done.