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:
> 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), alek...@nogin.org (personal) Office: Moore 04, tel: (626) 395-2200
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?
> 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.
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
> 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).
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
