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

[skaller <skaller@ozemail.com.au>]

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