[Haskell-cafe] Re: Dynamic binding / Scala paper

[Benjamin Franksen]

On Friday 24 June 2005 14:28, Andreas Rossberg wrote:
> Ralf Lammel wrote:
> > I would like to add a peer-reviewed clear reference
> > to the OOHaskell paper about the red herring that you mention.
> > I don't have such a reference. May I kindly ask you to offer
> > a few for selection?
>
> Off-hand, I recall a paper by Martin Odersky and the Scala people
> discussing their approach to the Expression Problem, and a related
> paper by Jacques Garrigue, where he proposes to solve it using
> OCaml's polymorphic variants. Both should be easy to dig up with
> Google, and probably contain further pointers.

Inspired by this post I read some of the available papers on Scala 
(among them the above).

I find Scala very, very interesting.

However, I am quite curious how the inventors of Scala managed to to 
write 100's of dense pages of papers, citing influences from 10's of 
other languages...

...and at the same time completely fail to even once mention Eiffel, 
which shares a lot of interesting features with Scala. The paper "An 
overview of the Scala Programming Language" lists allogether 10 
Authors. Have really none of those 10 authors ever heard of Eiffel and 
its famous attitude of "we are using multiple inheritance more often 
than loops"?

Ok, Eiffel has a few holes in its type-system, doesn't naturally 
integrate with Java/.Net, and doesn't support XML directly. And Eiffel 
does not support deferred types in class definitions.

But: IIRC, Eiffel was the first OO-language that almost completely 
solved the multiple-inheritance problem, providing solutions very 
similar to ones in Scala. For instance, mixin-type inheritance is 
easily possible in Eiffel. Also, Eiffel provides the same kind of 
automatic replacement of deferred (expected) methods and attributes 
with concrete (implemented) ones.

In a few places, Eiffel is even more general. For instance, in Eiffel 
you can even inherit two concrete methods with the same name. In order 
to resolve the name conflict you just rename one of them in your 
derived class. Furthermore, Eiffel does not distinguish between class 
and trait (although maybe the distinction is a good idea) without 
placing any restrictions on classes. Another nice feature of Eiffel is 
that access can be restricted in a very fine grained way, i.e. for each 
single method (or group of methods) you can give a list of classes that 
are allowed to call this method.

Ben