RE: Option types and O'Labl merger

From: Jacques Garrigue (Jacques.Garrigue@inria.fr)
Date: Wed Oct 13 1999 - 10:48:12 MET DST


To: christo@nextsolution.co.jp
Subject: RE: Option types and O'Labl merger
In-Reply-To: Your message of "Wed, 13 Oct 1999 14:35:44 +0900"
        <000701bf153c$cb83d960$0150ebca@nextsolution.co.jp>
Message-Id: <19991013104812Q.Jacques.Garrigue@inria.fr>
Date: Wed, 13 Oct 1999 10:48:12 +0200
From: Jacques Garrigue <Jacques.Garrigue@inria.fr>

From: "Frank A. Christoph" <christo@nextsolution.co.jp>

> > > If you really think that having such costless options would be useful,
> > > it is the time to make pressure to have them included in the merger.
> >
> > "Could we have costless options please, if it's REALLY not going to
> > complicate the compiler too much?"
>
> I don't really have an opinion on "costless options", but it is worth noting
> that including them is going to change the runtime's data representation,
> undoubtedly breaking many people's C-interfacing code (unless they use
> CamlIDL, I guess).

Indeed, and I was quite conscious of that when I made the remark,
since most of my libraries would need extensive changes.

But, then, the FFI is not part of the specification of the language
but only of its implementation. And changes have already occured
(unboxed float arrays for instance). If we're going to refuse a change
because of incompatibilities at the FFI level, the language is dead.

Another remark is that this would probably make writing C interfaces
by hand a bit easier: no need to create a box everytime you return an
option, with all the root registering machinery it may involve.
And if you choose NULL as representation for None, lots of code may
need no conversion at all.
If you use CamlIDL, well, everything is automated, so you don't
really. Stubs may be slightly smaller yet.

Actually it's difficult to evaluate the efficiency gain of such a
feature. With bytecode you cannot expect any real improvement in
performance, since allocation is fast enough, and you still need to do
some pointer comparisons with the unboxed scheme.

The main avantage I would see is that there is more room for
optimisation in the native code with such a representation.
Take for instance a default parameter "fun ?x [< 5 >] -> ..." in
O'Labl. The resolution might be reduced to (x86 code):

        cmp $ax, 0 ; check whether null pointer
        jne l1
        mov $ax, (5*2)+1 ; load Val_int(5)
    l1: ...

But again this is very compiler dependent, and the tests may be as
costly as the dereference.

And, coming back to the beginning of this discussion, this is a major
gain in space if we are going to use 'a option arrays (factor of 3).

Regards,

        Jacques
------------------------------------------------------
Jacques Garrigue, visiting INRIA from Kyoto University
                          Jacques.Garrigue at inria.fr



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:27 MET