Hacker News Reader

Comment by batterseapower | Hacker News Reader

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

View on HN

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.

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

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.

True and false work fine as singleton subclasses of the abstract class Boolean; see Smalltalk.

What prevents me from making a third subclass, Undetermined?

ADTs and enums are meant to prevent this.

> What prevents me from making a third subclass, Undetermined?

Smalltalk isn't about preventing things, it's about enabling them.

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

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++...

It's an integral part of Rust, which is Mozilla's new (imperative) language:

http://www.rust-lang.org/

They are also available in Ceylon (Redhat's Java successor):

http://ceylon-lang.org/

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.

This problem is also present in Haskell and it seems to work out pretty well there

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.

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.

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.

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

What I was saying, is that if you are to complain about lack of pattern matching syntax in Python, you want to consider that such syntax require concise and unambiguous handling of a number of cases:

matching a value of variable:

    |z when z = y -> print y

free matching with a bind:

    |y -> print y

matching several values:

    |2|3 -> print "2 or 3"

matching tuples:

    |2,3 -> print "tuple 2,3"

Now, if I'm trying to come up with such syntax for Python, I see immediate problems. For example, lets consider following syntax for matching several values:

    match x with:
        1: print "my string"
        2,3: print "2,3"

Would it be equivalent to matching a tuple (2,3) or matching one of the values 2 or 3? Ambiguous. So you need some other syntax. Let's try a few variations:

    match x with:
        1: print "my string"
        2:3: print "2 or 3"         # plain ugly
        2|3: print "2 or 3"         # interferes with '|' op
        in (2,3): print "2 or 3"    # too complicated 
        x in (2,3): print "2 or 3"  # elif was simpler

Or consider:

    match x with:
        1: print "my string"
        y: print y

Would that be matching a value of variable (|z when z = y -> print y), or free matching with a bind (|y -> print y)?

Having experimented with that a bit, I have a feeling, that it's just impossible to make up 'match' syntax for Python that would fit into the language. And I think that's why it is not there. And why we don't even want match syntax there. Now, of course I'd be happy to change my opinion, if somebody would rise up to the challenge and come up with some syntax that fits.

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

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

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.

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

Haskell is not an ML. Not even close.

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...

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.)

It also has a much more powerful, but also more complex type system.

To be precise, it's type _inference_ of Damas-Hindley-Milner + Typeclasses that poses the most gotchas. (Plain vanilla DHM is just ML. You can hack Haskell without class, but you can't get the class out of Haskell.)

Experience with Prolog helps, since a form of logical deduction, generally speaking, is what's happening behind the scenes. You could think of the compiler as applying AI to figure out the types. This kind of AI is magic when it works and baffling when it barfs.

One way out is to skip the AI entirely and annotate all the types by hand. Now the compiler only has to check types, not infer them. When it stumbles over imperfect code, the error messages become a lot more decipherable.

Right but Haskell is way closer to ML than it is to, say, lisp.

Reply on news.ycombinator.com