Re: Caml-list Digest, Vol 18, Issue 36

Re: Caml-list Digest, Vol 18, Issue 36

[Peter Sewell]

Philippe Wang wrote:
>Serge Aleynikov wrote:
>> What I meant by "strict typing" was performing type checks *at runtime*, 
>> i.e. that there are no unsafe operations.
>> 
>> Say, as an example, doing type checks of function arguments at runtime:
>> 
>> let f = fun i when is_integer (i) -> i
>>           | x when is_float   (x) -> int_of_float x;;
>> 
>> (raising Bad_match of some sort if neither one of the two guards pass)
>> 
>> Direct application of this could be for making the Marshal/Unmarshal 
>> modules more safe when marshaling data over files/sockets between 
>> applications written in heterogeneous languages.
>
>If you want to do that, use Lisp...
>Or use sum types...
>type t = Int of int | Float of float | ...
>
>OCaml forgets types at runtime !
>This means that you can't know without a huge cost (cf. SafeUnmarshal 
>costs), because what you can do in O(1) is to know whether a value is
>an int or a pointer...
>
>If OCaml is particularly efficient, it's probably mostly because of that!

If you want an upper bound on the cost of maintaining enough
information to calculate real type information at runtime, given
statically Caml-typable programs, you may like to look at the HashCaml
type-safe marshalling implementation
<http://www.cl.cam.ac.uk/~pes20/hashcaml/index.html>.  We didn't
investigate performance in detail, and the code is not highly
optimized, but the cost certainly didn't seem to be outrageous. 

Peter

Re: [Caml-list] Re: Caml-list Digest, Vol 18, Issue 36

[Till Varoquaux]

On 12/22/06, Peter Sewell <Peter.Sewell@cl.cam.ac.uk> wrote:
>
> Philippe Wang wrote:
> >Serge Aleynikov wrote:
> >> What I meant by "strict typing" was performing type checks *at runtime*,
> >> i.e. that there are no unsafe operations.
> >>
> >> Say, as an example, doing type checks of function arguments at runtime:
> >>
> >> let f = fun i when is_integer (i) -> i
> >>           | x when is_float   (x) -> int_of_float x;;
> >>
> >> (raising Bad_match of some sort if neither one of the two guards pass)
> >>
> >> Direct application of this could be for making the Marshal/Unmarshal
> >> modules more safe when marshaling data over files/sockets between
> >> applications written in heterogeneous languages.
> >
> >If you want to do that, use Lisp...
> >Or use sum types...
> >type t = Int of int | Float of float | ...
> >
> >OCaml forgets types at runtime !
> >This means that you can't know without a huge cost (cf. SafeUnmarshal
> >costs), because what you can do in O(1) is to know whether a value is
> >an int or a pointer...
> >
> >If OCaml is particularly efficient, it's probably mostly because of that!
>
> If you want an upper bound on the cost of maintaining enough
> information to calculate real type information at runtime, given
> statically Caml-typable programs, you may like to look at the HashCaml
> type-safe marshalling implementation
> <http://www.cl.cam.ac.uk/~pes20/hashcaml/index.html>.  We didn't
> investigate performance in detail, and the code is not highly
> optimized, but the cost certainly didn't seem to be outrageous.
>
> Peter
>

Gcaml (http://web.yl.is.s.u-tokyo.ac.jp/~furuse/gcaml/) also has types
informations at runtime. It seems to be pretty close to what has been
asked (ie simplicity of dynamically typed systems with security of
statical types). I haven't played with it, so I don't exactly know
what it does. However I do know it supposedly provides type safe
marshalling, which gets me to ask: what is the main difference between
marshalling in hashcaml and g'caml?

Haskel's type classes also brings these kinds of features, I've been
told they doesn't play nicely with the inference mechanism though...

As for safeUnmarshal AFAIK tests for compatibility: it tests if the
string can be unmarshall to a given type. However values of different
types may be represented by the same marshalled string (correct me if
I'm wrong).


Till