Re: [Caml-list] Obj.magic, Obj.t etc.

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Xavier Leroy <xavier.leroy@inria.fr>

> Right.  More generally, I have long advocated the exploitation of
> properties of the static type system in optimizing data
> representations, runtime system operations, and code generation.
> The above is just an exploitation of the property of "classic" ML that
> an array is always homogeneous (all elements have the same principal
> type).
> 
> A corollary is that if the type system changes significantly, some of
> these optimizations are invalidated.  Introducing a "top" type is one of
> these significant changes.  Quite frankly, I see zero practical uses
> of a "top" type, so why bother?

Well not exactly zero: here is one example (the mail is by me, but I
was answering a precise question)
http://caml.inria.fr/archives/200307/msg00064.html

Of course you can say: but we have objects for that, why bother?
And it's probably right.

Another reason is that it would allow to make both covariant-only and
contravariant-only variables generalizable in non-values. Not so
useful but any bit of polymorphism is good.

So I would agree that there is no compelling need for such a feature,
but not that there is zero practical uses.

Also, the opposite argument would be more convincing if there were
more examples showing that having a top type is bad for performance.
To me the current situation is more like: not worth changing the
implementation for it, but when designing from scratch this may be a
valid choice. If you're ready to work in a world of homegeneous
representations (i.e. no type-specialized representations).

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