[snip]
> 1. Introducing a match statement is lighter weight than
> defining a family of multimethods.

Sure for an instanceof test types alone, but when you then add things like sealed classes and matches on values there isn't much in it.

> 2. The alternatives are all gathered together in a match
> statement. I can't extend a match "from the outside". But
> I can add another override to a family of multimethods.
> (Good or bad?)

That isn't true, see Point example in chapter 28 of the Scalabook.

> 3. The dispatch rules for match statements are simpler.
> The dispatch rules for a family of multmethods resemble
> e overload resolution (albeit at runtime).

Yes, but you do need to generate errors to detect unreachable cases - which is the same procedure as you do with multiple dispatch (so not much in it)

> 4. An open multimethod is written in terms of the public
> features of its arguments while simple pattern matching
> systems need access to internal state.

No, if the multimethod is inside a class then it has access to private data just like any other class member does.

> In scala, we have the innovation of extractors which
> restore encapsulation. An extractor can be separate from
> the matched type in which case it only has access to
> public features.

A multimethod can be outside a class also and then it only has access to public members

> 5. Patterns can be nested and may involve values as well
> as types. Some multimethod systems are limited to
> dispatching on types.

No reason why any method, multiple or single dispatch, can't match on values. EG in Haskell and many functional languages you can write:

def factorial(1) = 1
def factorial(n) = n * factorial(n - 1)

> It is interesting to contemplate extending an existing
> family of multimethods with new overrides. ie my point
> t (2). Most of this thread seems to be discussing whether
> this ability is a can of worms in practice.

Not in my experience, in fact quite the opposite. Take chapter 28 of the Scalabook, it is a long chapter discussing the pitfalls of pattern matching for a well known method, equals. I would suggest that using mutimethods would be much simpler (see previous post).

Hi Mark,

> I tried to extend the Rational example from "Programming
> in Scala" in several respects. In the book it shows how to
> get 4 * 1/3 and 1/3 * 4 to produce the expected result
> (4/3). OK, but I also want 4.0 * 1/3 and 1/3 * 4.0 to
> produce 1.3333..., and here I failed. As I understand it,
> multimethods should be able to get the right answer for
> cases like this, but I don't see pattern matching helping.
>
Although any floating point number you can express on the JVM, float or double, could be represented by a rational number (because every floating point number has a finite number of digits), that doesn't mean you could represent them in a Rational as shown in the book, because in the book the numerator and denominators are Ints. Fortunately, you are wanting to go in the other direction. Given a floating point number, multiple it by a Rational number and get another floating point number. You would like to do this either way:

4.0 * (new Rational(1, 3))

and

(new Rational(1, 3)) * 4.0

If you can change class Rational, then you could at *, +, -, /, etc. methods that take Double, and that would give you the latter one. For the former, or the latter if you can't change Rational, you'd need to create an implicit conversion from Rational to Double. Here's what it looks like in the Scala interpreter. Before this code I just copied the final version of Rational shown in chapter 6 (in listing 6.5) and pasted it into the interpreter. Then:

scala> implicit def convert(rat: Rational) = rat.numer.toDouble / rat.denom.toDouble
convert: (Rational)Double

scala> val oneThird = new Rational(1, 3)
oneThird: Rational = 1/3

scala> 4.0 * oneThird
res0: Double = 1.3333333333333333

scala> oneThird * 4.0
res1: Double = 1.3333333333333333

> I tried to extend the Rational example from "Programming
> in Scala" in several respects. In the book it shows how to
> get 4 * 1/3 and 1/3 * 4 to produce the expected result
> (4/3). OK, but I also want 4.0 * 1/3 and 1/3 * 4.0 to
> produce 1.3333..., and here I failed. As I understand it,
> multimethods should be able to get the right answer for
> cases like this, but I don't see pattern matching helping.

Yes with multimethods you could do this. (You could also hand code multiple dispatch or use the Visitor pattern.)

Oops typo

>

> class ColoredPoint(x: Int, y: Int, val color: Color.Value) extends Point(x, y) { 
>   override def hashCode = 41 * super.hashCode + color.hashCode 
>   override multidef equals(this, that: ColordePoint) = (x == that.x) && (y == that.y) && (this.color == that.color)
> } 
> 

Should be

class ColoredPoint(x: Int, y: Int, val color: Color.Value) extends Point(x, y) { 
  override def hashCode = 41 * super.hashCode + color.hashCode 
  override multidef equals(this, that: ColordePoint) = (x == that.x) && (y == that.y) && (this.color == that.color)
  override multidef equals(this, that: Point) = false
  override multidef equals(that: Point, this) = false
} 

Howard,

> Chapter 28 of the Scala Book is great, particularly since
> I am a fan of multiple dispatch and the suggested solution
> is to hand code multiple dispatch :).

So, just for kicks, any thoughts on how PEC could some day work with Scala?