Re: Do interfaces make sense in multiple dispatch languages?

[email protected] wrote:
> Quoting Isaac Gouy <[email protected]>:
> 
> 
>>Was the motivation to remove interfaces from the language or to add
>>multiple inheritance (of state)? 
> 
> 
> They are two seperate issues that I mixed together. I will try to seperate them
> and then explain how the two ideas mix together:

Thanks for making this effort of clarification. It makes your message 
very pleasant to read.

> 1. What to do with "interfaces" in Nice
> 
> I think that the term "interface" and the phrase "implements interface" are both
> very confusing because they do not match the underlying abstract model of the
> language. In Java, we can say that an interface introduces a type with a set of
> operations defined on that type; the set of methods is the "interface". In Nice,
> all we can say is that an interface introduces a type; it does not define a set
> of methods. 

But if you say (adapting from Bryn's implementation of 'using') :


   interface Disposable {}

   void dispose(Disposable);

There is a "contract" attached to Disposable, which is that you must 
implement a dispose method. It's just that since you can define methods 
operating on Disposable anywhere, this contract is open to extensions.

Now I agree that "class Writer implements Disposable" might not be the 
best wording, because it will be the implementation of dispose that 
really implements the contract. The class declaration merely proclaims 
that the contract must be implemented.
It would sound good to read "class Writer is Disposable", but probably 
that's because Disposable is an adjective, which is not the current 
practice for all interfaces.

> 2. Whether to implement multiple inheritence of state.
> 
> Given the other (proposed) language features it seems it would not be too much
> of a stretch to support multiple inheritence like I explained in my previous
> email. But, I can't say whether it is a good idea or not. 

It might be possible, but the restrictions you mentioned might be confusing.

> Actually, with multiple inheritence it makes sense to have a "interface" or
> "type" construct if you were planning to distinguish between types vs. classes,
> and subtyping vs. subclassing. For example, if you wanted to support "class X
> subclasses Y { }" where X inherits everything from class Y but without meaing
> that X <: Y.

Is there any reason to want that? The only one I know of is that in 
selfish languages (those that dispatch solely on self/this) if you want 
binary methods or more generally covariant specialization, you get 
subclasses that are not subtypes. But that seems to me like (another) 
work-around for the lack of multi-methods, not a useful (nor intuitive!) 
feature.

> The more I think about this the more it seems I am suggesting that the Nice team
> re-implement Cecil. We should make a language comparison between Cecil and Nice
> to see what the advantages of each are.

If I remember correctly, Cecil started as a dynamically typed language, 
and they worked on adding a static type-checker to it, but I don't think 
it's complete. The type system is in any case very different from 
Nice's, which was the initial motivation to work on Nice. They have a 
Java front-end to the vortex compiler, but I'm not sure how well you can 
reuse Java libraries from cecil, and that doesn't allow to generate java 
bytecode. As far as I can see, development on Cecil seems stopped.

Daniel



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn