From: Damien <Damien.Pous@ens-lyon.fr>

> > This isn't a problem of soundness.
> > There is just no such thing as a "partially abstract" object type.
> there is no such thing...
> ...in the type system or in the compiler ?
> 
> Sorry for mixing variants and objects again, 
> but I have got the feeling that since the example I posted with variants
> works, the first example with objects could/should work :
> It seems quite natural and reasonable. So why should it be rejected...

Because instanciation/specialization only works for values, not for
types.
This is reasonable enough: once you have defined a type, you may use
it both in covariant and contravariant positions, so allowing to
specialize it would be unsound.
(So, yes, in the long run this is a soundness problem.)

The solution you describe with polymorphic variants use values, so
specialization works as expected.

> I don't really see what can prevent the compiler to do it.
> It looks like an additional check in the type checker,
> and almost nothing in the compiler
> (that's just a feeling, I never looked at ocamlc sources...)

Have a look if you have lots of free time :-)

> > But as shown above, you can easily simulate it by coupling an abstract
> > type with a coercion to an object type.
> still curious : are such "coercion identity functions" eliminated by the
> compiler ?

Unfortunately, no.
In general, functorial code (or object-oriented code) is much less
optimized than a first order style.
But it's not going to be very expensive either: just a few more jumps.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners