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

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

[Christopher Dutchyn]

In a few instances I've encountered code with these special types.
The former appears to be a way to "hint" the typechecker with
additional information, and the latter seems to be some sort of
catchall.

Where are these documented?  Are there any others?

Chris Dutchyn
cdutchyn@cs.ubc.ca

-------------------
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

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

[Jacques Garrigue]

From: Christopher Dutchyn <cdutchyn@cs.ubc.ca>

> In a few instances I've encountered code with these special types.
> The former appears to be a way to "hint" the typechecker with
> additional information, and the latter seems to be some sort of
> catchall.
> 
> Where are these documented?  Are there any others?

Related functions are all in the Obj module.
They are not documented as ML function because almost all of them can
break type safety when used incorrectly.

On the other hand, they are just equivalent to C macros described in
the "interfacing C" part of the manual, so you can consider this as
documentation.

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.

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

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

[Florian Douetteau]

>
> 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")  .

I don't know if the current runtime implementation makes other assumptions
of the same kind about the lack of subtyping;
for instance, the gc could avoid marking the content of an array starting
with an unboxed integer ? Same thing about list cells.

--
Florian

-------------------
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

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

[Jacques Garrigue]

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

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

[Marcin 'Qrczak' Kowalczyk]

Dnia czw 14. sierpnia 2003 10:34, Jacques Garrigue napisał:

> 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.

But now the check is required before polymorphic access. It happens in inner 
loops in almost all functions from the Array module.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
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

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

[Jacques Garrigue]

From: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
> Dnia czw 14. sierpnia 2003 10:34, Jacques Garrigue napisał:
> 
> > 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.
> 
> But now the check is required before polymorphic access. It happens in inner 
> loops in almost all functions from the Array module.

True, but you're not supposed to use polymorphic code for
high-performance computing. By the way you're not supposed to use
functionals either: the prefered approach, according to Xavier Leroy's
memo, is monomorphic code and for loops. Of course this limitation
only concerns inner loops.

My point was that even monomorphic code would need checks, reducing the
interest of float arrays to nil.

If you want to interpret my point as meaning that the current
dynamically distinguished float arrays are a bad idea (costly in
polymorphic cases, and limiting the semantics), you're free to do so.
I believe some designers of the language think so too.

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

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

[skaller]

On Thu, 2003-08-14 at 20:45, Marcin 'Qrczak' Kowalczyk wrote:
> Dnia czw 14. sierpnia 2003 10:34, Jacques Garrigue napisał:
> 
> > 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.
> 
> But now the check is required before polymorphic access. It happens in inner 
> loops in almost all functions from the Array module.

Then you lift the check out of the loop:
one check, two loops specialised for each case.


-------------------
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

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

[Marcin 'Qrczak' Kowalczyk]

Dnia pią 15. sierpnia 2003 12:32, skaller napisał:

> > But now the check is required before polymorphic access. It happens in
> > inner loops in almost all functions from the Array module.
>
> Then you lift the check out of the loop:
> one check, two loops specialised for each case.

It's not me who inserts the check, it's the OCaml compiler. Lifting it out 
of loops and of recursive functions like Array.to_list and Array.of_list 
would have to be done by the compiler.

IMHO a separate float_array type would be better. The main problem is that 
it would need a different syntax for element access and separate versions 
of Array functions. You couldn't use the same code polymorphically for int 
and float arrays, but we don't have polymorphic arithmetic anyway...

I wonder if it's improved when generics are adopted.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
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

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

[brogoff]

On Fri, 15 Aug 2003, Marcin 'Qrczak' Kowalczyk wrote:
> IMHO a separate float_array type would be better. 

I agree. 

> The main problem is that it would need a different syntax for element access 
> and separate versions of Array functions. You couldn't use the same code polymorphically for int 
> and float arrays, but we don't have polymorphic arithmetic anyway...

Also, we already have the same problem now with respect to array syntax for 
strings and bigarrays (and hashtables and ...). 

> I wonder if it's improved when generics are adopted.

I think it will improve a lot of things, if something like generics is in the 
language. However, there is another issue lurking here, about whether the 
Array element is boxed or not. In the Clean language the distinction is in the 
type system. 

-- Brian


-------------------
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

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

[skaller]

On Thu, 2003-08-14 at 18:34, Jacques Garrigue wrote:
> From: "Florian Douetteau" <Florian.Douetteau@ens.fr>

> 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.

Actually the technology to solve this exists in C++
in the sense it supports specialisations, indeed, that
is the *only* mechanism for polymorphism in C++ other
than the C technique of void* .. which is the same
as what most FP use with a bit of static type checking
of the needed casting thrown in :-)

The effect would be that you'd need to generate a switch
in the exeuctable code, if and only if both boxed arrays
and unboxed float arrays are used, and then only for
routines where the type variable could be instantiated
either way.

As in C++, whole program analysis is needed, so the
decision has to be deferred until link time. An important
point though is that the run time system doesn't need
any modification provided it can handle types (like float)
or many C structs which can be bitwise copied (that is,
don't contain any caml heap pointers).

Heh..one of the things you find when considering
expanded types is that most FP systems are based
on a kludged type system -- the assumption is
type values have a uniform representation and therefore
you can have type variables (not just macro names in
a meta language like in C++).

In general, that assumption is wrong, which makes
the type systems of dubious value. Its my guess that
at least three kinds of type variables would be useful:

(a) macros names (resolved at compile time)
(b) pointers (known copy semantics)
(c) arbitrary types

Case (c) is easier to implement than you might think,
since a type is almost completely characterised
by a few functions (copy constructors, assignment operator,
destructor .. etc).

Indeed, the biggest problem seems to be *synthesising*
new descriptor tables at run time. For example given
that a copy constructor is a C function pointer,
it isn't clear how to create a copy constructor for

	'a * 'a

Nevertheless it is clear an interpreter for some
kind of easily synthesised bytecode could be written
to solve this problem.


-------------------
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

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

[Xavier Leroy]

Jacques Garrigue writes:
>
> 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

Yes, that's a amusing example, but it just confirms the party line
that *any* function from module Obj is dangerous and must not be used
if one has any hope of type safety.

> From a subtyping point of view, this basically means that there cannot
> be any "top" element in the ocaml type system.

Florian Douetteau writes:

> To be fully accurate, it only means that the current implementation
> of the code generator would not support it directly.

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?

> I don't know if the current runtime implementation makes other
> assumptions of the same kind about the lack of subtyping; for
> instance, the gc could avoid marking the content of an array
> starting with an unboxed integer ? Same thing about list cells.

No, these optimizations are not done because 1- non-float arrays have
the same run-time tag as other data structures, e.g. tuples and
records, and 2- an unboxed int can also represent a constant
constructor from a sum or variant type.  

- Xavier Leroy

-------------------
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

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

[Jacques Garrigue]

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