Re: [Caml-list] Why can't I use constructors as functions?

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> | The old Caml V3.1 implementation treated constructors as functions like
> | SML. In Caml Light, I chose to drop this equivalence for several reasons:
> 
> I think you're forgetting that at some stage you must have re-introduced
> it.

You're correct, the "constructor as functions" was implemented in Caml
Light version 0.7.  Tremendous psychological pressure must have been
exerted on me to make me implement this, causing me to forget all
about it afterwards :-)

> I would be happy to have constructors curried or uncurried, but I don't
> see that exposing a distinct notion of arity serves any useful purpose.

It serves the following purpose: all implementations want to represent
specially a constructor that takes a tuple of arguments, e.g.
        C of int * int
representing it as one block tagged C with two integer fields, rather
than the "normal" representation as a block tagged C containing a
pointer to a block representing the pair.  This optimization is
crucial both for memory size (cuts down memory use by a factor of 5/3)
and for speed.

In combination with modules, it's very hard to perform this
representation trick transparently, i.e. as a compiler optimization.
The reason is that a module implementation can define

        type t = C of int * int
        type u = int * int
        let f x = (* code assuming that C(x,y) is represented as 1 block *)

yet its interface can abstract over u:

        type u
        type t = C of u
        val f : ...

and clients of the module assume a different representation for C,
namely that it has only one field containing "the" argument of C.
Some form of representation coercion or run-time type inspection is
necessary to deal with this case, and it can be extremely complex
(see the TIL compiler for an example).  

By exposing a notion of arity for constructors, we prevent the module
implementation above from matching the module signature "type t = C of u",
thus working around the problem.

More generally, I think the representation trick for constructors
taking several arguments is so crucial and so hard to perform as a
transparent optimization that it deserves to be exposed in the
language as a primitive concept of "constructor with arity".

> Isn't it conceptually simpler to have constructors behave as regular
> objects as much as possible? (Of course, not in pattern matching etc.)

As you said, constructors already have a special status in
pattern-matching, so it doesn't seem much more conceptually difficult
to treat them as a primitive concept distinct (and essentially
orthogonal) from functions.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr