Browse thread
[Caml-list] Obj.magic, Obj.t etc.
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Garrigue <garrigue@k...> |
| Subject: | Re: [Caml-list] Obj.magic, Obj.t etc. |
From: "Florian Douetteau" <Florian.Douetteau@ens.fr> > > As an interesting aside, I've discovered recently that even Obj.repr > > is dangerous: > > > > # Obj.repr;; > > - : 'a -> Obj.t = <fun> > > # let arr = Array.create 1 (Obj.repr 1.0);; > > val arr : Obj.t array = [|<abstr>|] > > # arr.(0) <- Obj.repr 1;; > > Segmentation fault > > > > >From a subtyping point of view, this basically means that there cannot > > be any "top" element in the ocaml type system. > > To be fully accurate, it only means that the current implementation of the > code generator would > not support it directly. > If subtyping was to be supported, an unboxed float array would be created > iff > its the compile-time type "float array" (it would be created boxed if typed > "Top array") . Not so simple: it would also mean that all polymorphic functions on arrays would create only boxed arrays, since their compile time type is not float array. As a result, the representation of float arrays would not be uniform, requiring a check before access, which would probably neutralize any performance advantage of having a special representation. Sure, this is an implementation problem. But not a simple one. The only simple solution would be to have a special type for float arrays, just like strings... highly incompatible. 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