Swift enums and Scala case classes both attempt to emulate ML/Haskell Algebraic Data Types. In the design goal there they both are identical.

Swift's enums are a more faithful translation than Scala's case classes (since case classes are more ambitiously/granularly typed, and this leads to some weakness [0]). Right now they're a little broken, though, since recursive enums lead to compiler bugs (here's are a few of my attempts to fight this: [1], [2]).

[0] http://stackoverflow.com/questions/25330359/what-are-the-pro...

[1] http://tel.github.io/2014/07/30/immutable_enumeration_in_swi...

[2] http://tel.github.io/2014/07/27/calkin-wilf-in-swift/

Not sure what weakness you're referring to in that SO post; the OP is actually saying otherwise:

> I have always considered the Scala variation to be on the advantageous side [relative to Haskell].

Daniel Spiewak does provide an answer that points out a weakness with scala collections when used with ADTs, but (G)ADTs of and in themselves are pretty damn elegant in Scala, arguably rivaling Haskell equivalent (provided we set aside Scala's slightly more verbose implementation).

Daniel's answer is not specific to Scala's collections library but instead any generic type unless it's set to be invariant. That ultimately leads to a tradeoff between soundness and convenience (as mentioned in comment toward Scalaz's Monad impl).

Ultimately, both of his points come from the idea that you genuinely want a mechanism for deferring information to runtime and case classes almost give that to you if it weren't for their default to greater typing granularity and covering it up with subtyping relations.

The point I made in the comments is that this throws away syntax directness almost everywhere and that tosses out a lot of inference.

Ultimately, Haskell's GADTs give you the same power as Scala's case classes, but they require you to actually ask for that level of type specificity and then provide an explicit and delimited family so that inference doesn't get as mucked up.

So, I think Scala is certainly workable... but in general disallows precision of desired expression, ironically, by defaulting to greater precision of actual "type".

(There's finally a totally pedantic argument to be had that "Inl and Inr aren't types" in some foundational sense. Of course you can consider them types and model a perfectly reasonable type system off of that consideration. That said, they're something a little different from your standard MLTT/BiCCC/TypeTheory/Logic types, fwtw)

Thanks, Scala collections in particular are unfortunately capable of wreaking havoc (Paul Phillips' infamous List(1,2,3).contains("your mom")) in surprising ways.

I'm not saying that Scala's approach to G(ADT)s is flawless (by any means), but it is powerful, and to cast a strength as a weakness is a bit disengenious, particularly when the SO user is in fact saying, what's the deal, Scala is superior to Haskell in this area.

Then again, Scala's terribly unpopular in the Haskell community and here on HN, so casting the language in a bad light is of no surprise.

FWIW, I really enjoyed that Twitter Bird pic tweeting out Haskell's logo in this language usage breakdown[1]. Heh, the language that everybody is talking about...and nobody is using O_o

Saying that, Haskell by all indications seems poised to take off, so I may be eating my words in future. We shall see, next 3 to 5 years on and off the JVM are going to be interesting times indeed ;-)

https://github.com/Dobiasd/programming-language-subreddits-a...

I truly disagree that Scala is superior. I think it's different and made an interesting encoding of ADTs. I also don't think Daniel was suggesting anything otherwise, though the op was.

Author of those slides here.

They were made on the next day after the language was presented on WWDC and were based purely on the first draft of the Swift book published online by Apple. Needless to say the book was more of a tutorial than a full-blown spec at that time and many important aspects were not covered (generics were lightly documented without much details).

Can you please provide details about generics in Swift and how exactly are they different from Scala's?

Edit: changed 'superior' to 'different'.

Don't bother, people will just say X is better than Scala here. They don't know the amount of research done by Odersky on generics and why Scala can not be easily beaten in this area at least.

Scala can't be easily beaten there? Man...have you used C#?

I mean, I use Scala every day, but C# gives you so much solely on reification and Scala manifests are a real poor patch.

Holy shit you have got to be joking. Really trolling now, are we? Take a look at things like Shapeless (https://github.com/milessabin/shapeless).

I've used Shapeless. It doesn't affect my actually writing code on a daily basis. Reified generics do.

How exactly?

I think that poster is saying that Swift's generics are not as good as C++'s, and even more not as good as Scala's.

"Miles away" is ambiguous, but I think it's "miles behind" in this context, given its proximity to "even" and "let alone."

I think you meant 'inferior'.

I agree - the examples given are almost infuriating. Whilst I can't comment on how idiomatic the Swift code is, the Scala code is anything but. There's little benefit to using a language like Scala if you're going to count the number of apples and oranges in a list by incrementing a mutable var for each type.

My problem with both languages is that you can count apples like that. If it can be done, it will be done.