[cap-talk] Deep attenuation, typed operations

[Sam Mason]

On Tue, Aug 14, 2007 at 09:45:51PM -0700, Charles Landau wrote:
> When I said "types have limitations", I meant that they don't capture 
> all the polymorphisms of an object - i.e. the fact that newFile 
> implements read just as file does. I don't think we want to make it 
> easy for people to thwart polymorphism. It seems like what you really 
> want is [read, file and all other types that are polymorphic with 
> file including types that haven't been invented yet]. I don't know 
> how to implement that.

Just to play devils advocate for a bit, if "newFile" has got a "read"
method like "File" then why don't you just extend it, polymorphism will
just work then.  If you want subtype polymorphism in a language that has
a mechanism to express it, you should probably be using it!  If you've
introduced a new interface that's not related to the original type then
the type system is going to think that two methods (even if they have
the same name) are unrelated---i.e. it's doing exactly what you told it
to.

If you really do decide that you want the above; you'd want something
that I know as "ad-hoc polymorphism", BitC and Haskell both have it and
in their implementation it's known as type classes. You would then be
able to say that some bit of code returned an object on which it was
valid to call a "read" method with these parameters and returning this
other type.

I'm not sure if this is such a type level feature is a good thing for
the specification of inter-program types.  It's a great thing to use
inside programs as it allows all sorts of nice things to be expressed,
but (in my view) they tend to be shortcuts (i.e. '+' lives in a Number
type class in Haskell allowing integer, floating point and what ever
else wants to pretend to be a number work nicely) rather than big
structuring things---Monads are one of the few exceptions to this.


  Sam