Stéphane Glondu a écrit :
> Guillaume Yziquel a écrit :
>> Because subtyping seems more efficient than applying a noop function.
>> And this code might run really often, so I do not like very much the
>> idea of having noop functions running really often.
> 
> FWIW, I don't think you have any penalty if you declare your identities
> as externals like Obj.{repr,obj,magic}. Yuk, some might say... but we
> are in the context of bindings to other languages anyway.

Yuk indeed. The subtyping was also a way to avoid Obj.magic in the first 
place and keep doing things cleanly.

I'm not so sure about runtime penalty in this context.

>> Moreover, having conversion functions is not really handy, from a
>> syntactic point of view: It's quite convenient to write something like
>>
>> let f : string -> obj :> string -> float t = blah blah blah...
>>
>> than doing the explicit, runtime, casting in the definition of f.
> 
> It's more convenient for me write letters and parentheses than the
> symbol ":>" :-)

That's a matter of taste, I guess :-)

> IIUC, these conversion function are not to be used often, are they? What
> you want is the equivalent of Obj.{repr,obj}, but for values of some
> other language, right?

Yes, for the values of some other language.

It depends: they are to be used often for people wanting to make 
bindings of R / Python code. (Even tough I plan to use syntax extensions 
to ease the pain, something like 'module Nltk = python module nltk'. But 
that's a long term perspective.

For people using the binded code, subtyping shouldn't be necessary.

> Are you planning to leak your "tau", "typed" and "untyped" types out of
> the module? If so, inferred types are likely to refer to those, which
> might be very confusing (unless you resort to a lot of type
> annotations). If not, you'll have to use explicitly the coercion
> functions outside of the module anyway.

Yes.

I'm not satisfied with this. (Renaming 'tau' to 'wrapped' would be 
better, I guess).

But somehow, I believe that it's an OCaml issue rather than an issue 
with my approach. I mean, why should it be impossible to *express* in 
the .mli file something like type 'a t = private obj and obj = private 
'a t without resorting to extra intermediary types and contravariant 
phantom types? Couldn't we just dump the type inequations and 
co/contra-variance information (which would require another syntax for 
types, I guess)?

But there's another problem for weirder typings that would need 3 
different categories of types (R ?). 2 conversion functions is OK. 6 
conversion functions is clearly a pain... And concerning R's quirky type 
system, I'm probably optimistic with the number 3.

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/