Comments on Electric Sheep Blog: Twitter on Ruby and Scala

Sidu, This is how you will do it in Scala. def ...

2009-04-23T12:00:00.000+05:30

Sidu,

This is how you will do it in Scala.

def firstElement[T](l: List[T]) = l match {
case x :: xs => Some(x)
case _ => None
}

Scala pattern matching is interesting because it marries OO with pattern matching. For pattern matching you need to expose the object composition. This in general goes against encapsulation principal of OO. But Scala enables this exposure in controlled ways:

1. Constructor signature is exposed for only those classes marked as 'case classes'
2. Provides unapply method for more control on what you want to expose

The latter is called "Extractors" and is considered fundamental contribution of Scala. I think pattern matching is still a small part of the whole Scala phenomenon which is trying to bring so many academic ideas to the mainstream.

Sure, I understand what you're saying about th...

2009-04-22T15:13:00.000+05:30

Sure, I understand what you're saying about the exhaustive check, no problem there. In an OO language, preventing this kind of problem lies in the hands of the developer (encapsulated, unit tested blah blah). No arguments from me on the exhaustiveness checking front. I would disagree with your assertion that polymorphic dispatch isn't that important, but that could just be my ignorance talking (see below for a sample illustrating what I mean).

Option types seem to be syntactic sugar *in Scala* I should have said. In a functional language they make a lot of sense (which is why I mentioned the Maybe monad, which is what I'm more familiar with from Haskell). In Scala, the syntactic sugar saves you from the problem that you just described - having a ton of NullThis/NullThat classes, no doubt about that.

My confusion stems from the fact that in Scala seems to be offering pattern matching on nominative types as an alternative to polymorphic OO based invocation, but *both* are available though they are equivalent (in fact I suspect the latter is implemented by using the former).

Let me illustrate with a Haskell sample from the free Haskell guide (and it uses option types :)):

firstElement :: [a] -> Maybe a
firstElement [] = Nothing
firstElement (x:xs) = Just x

I'm not sure about how something equivalent would be implemented in Scala?

The examples above were shamelessly ripped off fro...

2009-04-22T01:48:00.000+05:30

The examples above were shamelessly ripped off from Practical Foundations for Programming Languages by Robert Harper.

Dispatch on structural types using pattern matchin...

2009-04-22T00:33:00.000+05:30

Dispatch on structural types using pattern matching maybe an application of pattern matching (although I don't see value since it can be achieved with if instanceof {type defn} else, switch case etc.), but I still think that the real value of pattern matching is exhaustiveness checking, which is a tool for code evolution. Consider (code in ML, but is intuitive enough):
datatype expr =
Numeral of int |
Plus of expr * expr |
Times of expr * expr

Think of datatype as a union type (its a sum type in ML in jargon), it can be Numeral, or Plus or Times

and the function:
fun eval (Numeral n) =
Numeral n
| eval (Plus (e1, e2)) =
let
...
end
| eval (Times (e1, e2)) =
let
...
end

If the definition of expr was changed to:
datatype expr =
Numeral of int
| Plus of expr * expr
| Times of expr * expr
| reciprocal of expr

The compiler will give you a warning at compile time because the function eval is incomplete - it doesn't account for exprs of type reciprocal. Hence, you don't accidentally break code that is in another part of the program.

Options types are not syntactic sugar, they have their own semantics. An option type is defined as

datatype 'a option = NONE | SOME of
'a

(also a sum type), and they are not limited to null pointers substitutes. For example they can be used for functions that expect two parameters but one can be optional, in which case the functions evaluates a default value.

The null object pattern seems unusually unwieldy because with it you may have to define tons of NullMyType classes or inherit all your classes from a Null type.

As an aside, it is not possible for options types as a whole to be syntactic sugar for an object oriented pattern because they have existed in ML since the 70s.

> Well, in a system that is large > enough ...

2009-04-21T16:07:00.000+05:30

> Well, in a system that is large
> enough it is simply not possible to
> make it completely object oriented
> so that you never have to do an
> instanceof.
There are very special cases (the equals() method for one) where it is acceptable. Otherwise instance_of? indicates bad code at that layer or the layer immediately below it. Basically, it indicates a problem with the people writing the code, not with the language itself.

Option types in Scala are basically nice syntactic sugar for null objects, which is good, but it is still a nice wrapper over an existing OO pattern, not something radically different. No Java/C# codebase I've seen in ThoughtWorks has many nil checks, except at library or input boundaries, and in the latter case they are isolated at the boundaries of the system using null objects.

However, whether you use null objects or a Maybe monad depends on the mechanism for polymorphism; scala which claims to support both OO and functional code seems odd, because my (limited) understanding tells me that dispatch on structural types rather than nominative types is where the real value of pattern matching lies; Scala's pattern match on the other hand seems to match nominative types which simply replicates polymorphic OO based method dispatch. Perhaps I'm missing something?

Disclaimer:- My rants above are mostly inci...

2009-04-21T11:39:00.000+05:30

Disclaimer:- My rants above are mostly incited by Scala. I think it's a platform that's trying to achieve too much in one package. But that's just a personal opinion.
- I like functional programming and pure FP-style pattern matching as it forces you to define specializations of as an atomic whole. Tremendous improvement in readability.

@Darpan- Hmm... interesting. I'd be a whole lot m...

2009-04-21T11:32:00.000+05:30

@Darpan-

Hmm... interesting. I'd be a whole lot more appreciative if it were a compile error rather than a warning, though; case analysis should be a fundamental feature.

Either way, Scala allows you to mark pattern matching on even sealed classes as @unchecked and apparently Erlang doesn't even give you a warning! (Yikes and Jinkies!!!)

The keyword sealed will force exhaustivenes...

2009-04-20T21:00:00.000+05:30

The keyword sealed will force exhaustiveness checking of the cases, and the scala compiler will give you a warning.

Correction: functional languages will give you a n...

2009-04-20T19:43:00.000+05:30

Correction: functional languages will give you a non-exhaustive match warning.

Functional languages will give you an error you if...

2009-04-20T19:32:00.000+05:30

Functional languages will give you an error you if you miss a case.

My comment was general about pattern matching, not particularly for Scala. I will have to read what Scala provides but I'd be surprised if it doesn't give a warning or error or mandate a default case. Because exhaustiveness checking is one of the points of pattern matching.

@Darpan, not sure what you're hinting at, but AFAI...

2009-04-20T18:48:00.000+05:30

@Darpan, not sure what you're hinting at, but AFAIK you can write 'match'es in Scala that don't cover all the 'case's. (PS- that comment was very Scala specific)

I agree that pattern matching in pure functional languages such as Erlang and Haskell is much better; flipping the paradigm over from imperative to declarative turns cases into a neat way to specialize problem definitions. Though, I'm not sure if either of them ensures (read enforces) that you cover all cases; but that's probably my inexperience/ignorance speaking.

Pattern matching is not a glorified switch case li...

2009-04-20T18:08:00.000+05:30

Pattern matching is not a glorified switch case like mentioned here by Saager Mhatre. It is a way of making sure you cover all cases which without pattern matching is simply not possible. In the example mentioned, are you sure that there isn't a Baz case you should cover?

As for your object oriented suggestion of never using is_a or instanceof (I am more familiar with this). Well, in a system that is large enough it is simply not possible to make it completely object oriented so that you never have to do an instanceof. And not everyone can code or design like some folks from Thoughtworks (or refactor :) ).

For your null pointer discussion, you should google Tony Hoare and his billion dollar mistake on null pointers. Having option types guarantees not having a null through the type system which is not only a big software engineering advantage but also an efficiency improvement.

Yikes! foldr!! Haskell!!!
You just went waay beyond my circle of knowledge. Haskell's still on my 'to pick up ' list. But I was talking about Scala-style-case-class-based-pattern-matching.

Oh, and as for the 'is_a?', why even start by repeating their mistakes?

Isn't

foldr f z [] = z
foldr f z (x:xs)...

2009-04-07T12:49:00.000+05:30

Isn't

foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)

an aesthetically pleasing use of that switch case? When there are objects involved though, I would tend to agree with you.

About the is_a? allegation, see Connection#http; looks familiar?

My Net::Http code is taken from there because I know they have handled more edge cases than I care to tackle now. But I have my eye on it and it will be gone soon. This kind of code is one of the reasons why ActiveResource annoys me and I'm writing Wrest ;)

Hmm... intewesting! An 'is_a?' hater who writes 'i...

2009-04-07T03:36:00.000+05:30

Hmm... intewesting! An 'is_a?' hater who writes 'is_a?' code...
Uri#https?

Somehow pattern matching always seems like a glori...

2009-04-07T03:10:00.000+05:30

Somehow pattern matching always seems like a glorified switch-case to me; the eyesore of a linguistically concealed if-else is only exacerbated by the fact that the conditionals are based on the Type of the object being matched. Wait, did I just describe a really cute way of writing...

swith(object.class) {
case Foo: ...
case Bar: ...
...
}

... ?

Egads! @-}

2009-04-07T03:09:00.000+05:30

This comment has been removed by the author.