Typing unmarshalling without marshalling types

Typing unmarshalling without marshalling types

[Michel Mauny]

Dear all,

We are pleased to announce a patch for Objective Caml that provides
type safe unmarshalling functions. In short, the main features are:

  - a type for type representations ('a tyrepr, a singleton type)

  - unmarshalling functions like the following:

       SafeUnmarshal.from_string:  'a tyrepr -> string -> int -> 'a

such that

       SafeUnmarshal.from_string ty str off

returns the value whose marshal is the string str (starting at offset
off) and gives it the type (represented by) ty, if possible. If the
value cannot be of type ty, the function fails.

For instance,

       SafeUnmarshal.from_string  [^ ( float *  int ) ^] str 0

asks the (memory representation of the) unmarshalled value to be
compatible with the type (float * int).

  - there is no type information in the marshalled data: marshalling
functions are not modified by this patch.

  - classical (unsafe) unmarshalling functions are still available.

The easiest way to obtained a patched version of OCaml is to download:

  http://www.pps.jussieu.fr/~henry/marshal/src/make_source_tree.sh

and to execute the following sequence:

./make_source_tree.sh ocaml-ty && cd ocaml-ty && ./configure && make world &&
make -C otherlibs/safe_unmarshaling top

The last command of the sequence runs the patched OCaml toplevel.

More information at:

  http://www.pps.jussieu.fr/~henry/marshal/

Have fun,

-- Grégoire Henry and Michel Mauny

Re: [Caml-list] Typing unmarshalling without marshalling types

[Aleksey Nogin]

On 23.06.2006 02:13, Michel Mauny wrote:

> Dear all,
> 
> We are pleased to announce a patch for Objective Caml that provides
> type safe unmarshalling functions. 

I've looked at the examples from your web page and it looks really 
great! What are the chances of this being included in the "mainstream" 
OCaml distribution some time soon?

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Moore 04, tel: (626) 395-2200

Re: [Caml-list] Typing unmarshalling without marshalling types

[brogoff]

On Tue, 27 Jun 2006, Aleksey Nogin wrote:
> On 23.06.2006 02:13, Michel Mauny wrote:
> > Dear all,
> >
> > We are pleased to announce a patch for Objective Caml that provides
> > type safe unmarshalling functions.
>
> I've looked at the examples from your web page and it looks really
> great! What are the chances of this being included in the "mainstream"
> OCaml distribution some time soon?

I agree that this is one of those highly desired features for OCaml that
we've been waiting for for a long time. If it were part of the mainstream
distribution, I'd use it.

I'm curious as to what happened to GCaml now. A while ago it appeared that
GCaml would bring overloading, dynamic types, and type safe marshalling to
Caml. Have the main Caml team concluded that folding GCaml into Caml proper is
not a desireable goal?

-- Brian

Re: [Caml-list] Typing unmarshalling without marshalling types

[Jonathan Roewen]

Hi,

I used your shell script to build it, and mkcamlp4 doesn't want to
play nice (complains that odyl.cmo is not a bytecode object file).

Jonathan

On 6/23/06, Michel Mauny <Michel.Mauny@ensta.fr> wrote:
> Dear all,
>
> We are pleased to announce a patch for Objective Caml that provides
> type safe unmarshalling functions. In short, the main features are:
>
>  - a type for type representations ('a tyrepr, a singleton type)
>
>  - unmarshalling functions like the following:
>
>       SafeUnmarshal.from_string:  'a tyrepr -> string -> int -> 'a
>
> such that
>
>       SafeUnmarshal.from_string ty str off
>
> returns the value whose marshal is the string str (starting at offset
> off) and gives it the type (represented by) ty, if possible. If the
> value cannot be of type ty, the function fails.
>
> For instance,
>
>       SafeUnmarshal.from_string  [^ ( float *  int ) ^] str 0
>
> asks the (memory representation of the) unmarshalled value to be
> compatible with the type (float * int).
>
>  - there is no type information in the marshalled data: marshalling
> functions are not modified by this patch.
>
>  - classical (unsafe) unmarshalling functions are still available.
>
> The easiest way to obtained a patched version of OCaml is to download:
>
>  http://www.pps.jussieu.fr/~henry/marshal/src/make_source_tree.sh
>
> and to execute the following sequence:
>
> ./make_source_tree.sh ocaml-ty && cd ocaml-ty && ./configure && make world &&
> make -C otherlibs/safe_unmarshaling top
>
> The last command of the sequence runs the patched OCaml toplevel.
>
> More information at:
>
>  http://www.pps.jussieu.fr/~henry/marshal/
>
> Have fun,
>
> -- Grégoire Henry and Michel Mauny
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Typing unmarshalling without marshalling types

[Jonathan Roewen]

> I used your shell script to build it, and mkcamlp4 doesn't want to
> play nice (complains that odyl.cmo is not a bytecode object file).

Ohh, it's a shell script! And ocaml doesn't encode path info for
ocamlc from the setting of prefix in the configure script.

I'm sure that's a quick fix from the ocaml team for the next release :-)

Jonathan

Re: [Caml-list] Typing unmarshalling without marshalling types

[skaller]

On Thu, 2006-06-29 at 09:20 +1200, Jonathan Roewen wrote:
> > I used your shell script to build it, and mkcamlp4 doesn't want to
> > play nice (complains that odyl.cmo is not a bytecode object file).
> 
> Ohh, it's a shell script! And ocaml doesn't encode path info for
> ocamlc from the setting of prefix in the configure script.
> 
> I'm sure that's a quick fix from the ocaml team for the next release :-)

It isn't broken. The need to search the environment for the 
interpreter is mandated by the requirement scripts invoking
the names of ocaml executables are transparent with respect
to both:

(a) whether the code is bytecode or native code
(b) the machine it runs on

Hard coding the location of the interpreter breaks
requirement (b): it prevents shipping bytecode
from one machine to another because two people may
have installed the interpreter in different places
(indeed may be running different OS!)

If you KNOW you have bytecode you can invoke the
interpreter explicitly, in which case your shell language
already allows you to specify the location.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Typing unmarshalling without marshalling types

[Jonathan Roewen]

> It isn't broken. The need to search the environment for the
> interpreter is mandated by the requirement scripts invoking
> the names of ocaml executables are transparent with respect
> to both:
>
> (a) whether the code is bytecode or native code
> (b) the machine it runs on
>
> Hard coding the location of the interpreter breaks
> requirement (b): it prevents shipping bytecode
> from one machine to another because two people may
> have installed the interpreter in different places
> (indeed may be running different OS!)

Err, what? OCaml already embeds the full path in bytecode (on
unix-like systems). How should this be any different for an ocaml
compiler tool?

As an example: ocamlmktop DOES embed the full path. Also, paths to
things like stdlib dir etc are full paths embedded in the compiler
tools as well (iirc).

Re: [Caml-list] Typing unmarshalling without marshalling types

[skaller]

On Thu, 2006-06-29 at 10:27 +1200, Jonathan Roewen wrote:
> > It isn't broken. The need to search the environment for the
> > interpreter is mandated by the requirement scripts invoking
> > the names of ocaml executables are transparent with respect
> > to both:
> >
> > (a) whether the code is bytecode or native code
> > (b) the machine it runs on
> >
> > Hard coding the location of the interpreter breaks
> > requirement (b): it prevents shipping bytecode
> > from one machine to another because two people may
> > have installed the interpreter in different places
> > (indeed may be running different OS!)
> 
> Err, what? OCaml already embeds the full path in bytecode (on
> unix-like systems). 

Then the codes won't be shippable.

> How should this be any different for an ocaml
> compiler tool?

It can be different for an installed tool set of ocaml
tools, but not for external executables such as CL.EXE,
gcc, etc. I not only can but DO upgrade these tools
independently of Ocaml.

Hard coding paths in executables is a bad idea.
The right way to do this is to make the client executables
(or libraries) arguments, and then provide a shell script 
which has these arguments hard coded. That way it's easy to 
reconfigure your system with a text editor.

IMHO of course. Hard coded paths are easier for dumb usage ..
until you get tied in a knot upgrading things and have no
idea what the problem is because the encoding isn't visible.
Coupling should be explicit -- basic design principle
(see OOSC, Meyer).

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net