Re: Option types and O'Labl merger

Re: Option types and O'Labl merger

[Francisco Valverde Albacete]

 Jacques Garrigue wrote:

 > By the way, and this also an answer to another mail I saw recently,
 > O'Caml and O'Labl are going to merge soon. That is, O'Labl features
 > will be merged into the official O'Caml release (beware though that
 > the syntax may be slightly changed to fit everybody's taste).

 I think it is only just that we thank everybody working in the merge. I know
 I am more than willing to pay for the adaption cost.

     Francisco Valverde
     Universidad Carlos III de Madrid

RE: Option types and O'Labl merger

[Jacques Garrigue]

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

RE: Option types and O'Labl merger

[Frank A. Christoph]

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

--FAC

Option types and O'Labl merger

[William Chesters]

Jacques Garrigue writes:
 > By the way, and this also an answer to another mail I saw recently,
 > O'Caml and O'Labl are going to merge soon.

hey hey :-)

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

Option types and O'Labl merger

[Jacques Garrigue]

From: chet@watson.ibm.com
> Of course, it is problematic that "None" and "Some None" are
> indistinguishable.  But is it a reason to not have such a facility (as
> a storage-cost-free "option" type constructor)?
> 
> I'd like to believe that the answer is "no" -- that the efficiency
> values of such a type-constructor outweigh the semantic difficulties.

In fact the semantic problem is not that bad. When I implemented
O'Labl, I had also the idea that it would be nice to have option types
without space (and dereference) cost, particularly since options are
used to implement optional arguments. I even went as far as
implementing it once, but dropped it since didn't make a big
difference in efficiency, and might become a pain to maintain.

The idea is just to represent Some^n(v) (the Some constructor applied
n times to v) as v when v is not an option, and Some^n(None) as n. To
be more precise, since you want to distinguish it from (n : int), you
represent it as a pointer in an unused memory area. Word addresses
starting at 0 would be a possible approach. Semantically this was
correct since ML polymorphism is not strong enough to allow the
dynamic creation of Some^n(None) for an arbitrary n. That is, the
maximum n is a function of the program, and not of its input.
Remark however that since you have polymorphic recursion in O'Labl
now, this is no longer true, meaning that you would need a runtime
check to make sure that you don't create wrong values.

By the way, and this also an answer to another mail I saw recently,
O'Caml and O'Labl are going to merge soon. That is, O'Labl features
will be merged into the official O'Caml release (beware though that
the syntax may be slightly changed to fit everybody's taste).
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.

Regards,

	Jacques

> >>>>> "WC" == William Chesters <williamc@dai.ed.ac.uk> writes:
> 
>     WC> The problem is that if you have a value of the type `int
>     WC> option option', you have to be able to distinguish between
>     WC> `None' and `Some None'!  If both the enumeration-indirections
>     WC> are elided, you can't; if only one of them is, you have
>     WC> inconsistency which would presumably have to be resolved using
>     WC> whole-program optimisation or something.
> 

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