[eli_gottlieb]

>My only big gripe with Scala is that OO syntax is a blight on the world. They should have provided multi-methods instead, so everything could be done with functional syntax.

I actually disagree. Functional syntax means that you need to start using qualified names or polluting your namespace (think of module/import usage in Python, but without OOP dot-notation). I like being able to say:

    val herp: Option[Derp] = hurr()
    herp.getOrElse(Darpity)

Leaving aside the awful metasyntactic variables, the `getOrElse` method could exist on any number of classes (stuff like `map` sure does!), but I never have to use a qualified name to get the right one. I use dot-notation on the object itself to qualify the method name.

[chc]

Do you find that's a problem with CLOS or Clojure multimethods? Because I never noticed much of what you seem to be talking about.

[eli_gottlieb]

As I said above, think about a method like map.

    map :: [a] -> (a -> b) -> [b]

Well, actually, any functor has a map method, by definition! So we'd have to write a type-class:

    class Functor f where
      fmap :: f a -> (a -> b) -> f b

Now how would we represent this as a generic function?

    method fmap<a,b>(as: Functor<a>,f: a -> b): Functor<b>

And then implement specialized methods for each actual functor?

    override fmap<a,b>(as: List<a>,f: a -> b): List<b>

Now everything involving functors performs a dynamic dispatch and might lose type information at its call-site, and we now have to deal with Functor<a> being some kind of superclass, a superclass without data slots of its own just to accommodate our need for this "interface".

In Scala, rather than doing that, we would just define Functor[A] as a trait:

    trait Functor[A] self => {
      def map[B](f: A => B): self[A]
    }

And now every time I call the map method on a Scala object, it statically dispatches via dot-notation. So my compiler knows that calling map on a List[A] gives me back a List[B], and that calling map on an Option[A] gives me back an Option[B], and I didn't need any implicits to get it done.

[nessus42]

I do not see why your worries cannot be addressed. In fact, IIRC (it's been a while), the programming language Cecil does just that.

http://www.cs.washington.edu/research/projects/cecil/www/cec...

[eli_gottlieb]

Well, let me take a deeper look at the material. I've based most of my own language work on multimethod systems like those of Cecil, but there's a few things I immediately see on the page:

* Cecil divides its type system from its object-inheritance-overriding system. Huh?

* Cecil is dynamically typed with static sprinkles on top. So we have dynamic vtables, and also F-bounded polymorphism.

* Methods are referred to as being attached to objects, even though they are multimethods. This appears to imply asymmetric multimethods. Again, huh? What a strange design decision to make!

* Cecil offers nothing for dealing with ad-hoc polymorphism (ie: operator overloading). Admittedly, when Cecil was published, type-classes didn't even exist yet.

[nessus42]

Methods are referred to as being attached to objects, even though they are multimethods. This appears to imply asymmetric multimethods. Again, huh? What a strange design decision to make!

Method dispatching is done symmetrically on the arguments in Cecil.

[eli_gottlieb]

OK, I've read their doc now. And what I can say is, they don't solve the problem I've mentioned at all. Their dot-notation is just syntactic sugar for an "ordinary" multimethod call. It does nothing for module selection.

This means you've got to either use qualified module names, make sure never to import two modules that export an identically-named method, or (if the methods have similar signatures) resort to a type-class.

[nessus42]

think of module/import usage in Python, but without OOP dot-notation

I don't find that to be a problem. In fact, I love Python's module and import system. And the worst thing about Python is it's OO dot notation. I wish that Python had multi-methods too, and no OO-style method calls.

[pka]

So instead of writing herp.getOrElse(Darpity) you'd write getOrElse(herp, Darpity)

Polymorphism doesn't need to be tied to the first argument's type, it can depend on any number of properties of any number of arguments (see CL's and Clojure's multimethods).

[eli_gottlieb]

I'm not talking about polymorphism at all. I'm just talking about namespacing, name look-up for the method. Think of a world in which any number of classes might have a `getOrElse()` method, and they don't all do the same thing (so they're not just all methods of a single generic function). Now, how does the compiler know which one you're calling?

We could use some form of static overload resolution (like type-classes). However, it really does seem (to me) to be easier to just resolve the static overload based on the static type of the first argument, and then throw the rest of the overloading problems at dynamic dispatch.

When you think of a class as both a type and a module, it gets clearer. Many classes in the Scala collections library have a `map()` method. We could code `map()` as a single, universal generic function that dynamically dispatches on its first argument type... but nobody ever cared to override map as a virtual method anyway and that doesn't give us a consistent return-type at all. All we really want to say is that calling map over a `[a]` with a function `a -> b` returns a `[b]`.

[nessus42]

So, what you're saying is that we all of parametric polymorphism, ad hoc polymorphism, and subtype polymorphism, right?

You'll get no argument from me, but that doesn't mean that there should be an unfortunate syntactic distinction between the three.

[nessus42]

The above should read, "So, what you're saying is that we need all of [...]".

Sorry about that!

[eli_gottlieb]

I'm saying, what happens if more than one module provides a getOrElse() method?

In "classical" OOP, the type of the "dotted" parameter, the this pointer, the method receiver, tells the compiler to look in its own module/namespace for the method name.

If we just write getOrElse(herp,Darpity), then we now have to either make getOrElse a type-class method (type-classes are equivalent to certain usages of modules) to recover the same functionality of looking up the appropriate method, or we have to write herpModule::getOrElse(herp,Darpity).

[nessus42]

As I understand it, in statically typed languages that support multi-methods, you import the generic function declaration for a multi-method. This multi-method can be defined in zillion different modules. You only have to import the generic function declaration, not any of the function definitions. The generic function declaration can be parameterized, just like parameterized declarations in Scala. Single or multiple dispatch may be used to locate a method definition.

So, yes, your code does need more import statements. I don't consider this to be a problem. Your code, however, does not need to qualify the functions that it calls with the module where the function is defined.

[eli_gottlieb]

You would have to qualify the call with the module where the generic function is defined. Otherwise, you could import two modules that both define a generic function named foo() -- but whose foo() functions do completely different things.