[Caml-list] Typing unmarshalling without marshalling types
Michel Mauny
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 worl
d &&
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
Aleksey Nogin
> 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: no...@cs.caltech.edu (office), ale...@nogin.org (personal)
Office: Moore 04, tel: (626) 395-2200
brogoff
> 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
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).
Jonathan
On 6/23/06, Michel Mauny <Michel...@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 worl
Jonathan Roewen
> 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
skaller
> > 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
Jonathan Roewen
> 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).
skaller
> > 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
_______________________________________________