From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA07303; Mon, 20 Aug 2001 18:54:19 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA06929 for ; Mon, 20 Aug 2001 18:54:18 +0200 (MET DST) Received: from cahors.inria.fr (cahors.inria.fr [128.93.8.84]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f7KGsF920813; Mon, 20 Aug 2001 18:54:15 +0200 (MET DST) Received: from localhost (IDENT:furuse@cahors.inria.fr [128.93.8.84]) by cahors.inria.fr (8.11.0/8.8.7) with ESMTP id f7KGsEw15115; Mon, 20 Aug 2001 18:54:15 +0200 Date: Mon, 20 Aug 2001 18:54:13 +0200 (CEST) Message-Id: <20010820.185413.84976020.Jun.Furuse@inria.fr> To: bpr@best.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] Segfault in a native code multi-threaded program From: "Jun P. FURUSE" In-Reply-To: References: X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://pauillac.inria.fr/~furuse/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hello, > > > > > > It would be very nice to be able to rely on Marshal as safely as on > > ocaml typing. Just to be sure that if I expect an int * string, I will > > effectively receive an int * string or raise an exception. It could > > probably be done using the same tricks as used in printf formatters. > > > > > > A more type safe marshaling framework is way up there on my list of > desired enhancements. I think this will be part of the extensional > polymorphism enhancements that you can see now in G'Caml. Yes. I did not announce this feature since it did not work in the last version. I quickly fixed it and replaced the source archive at http://pauillac.inria.fr/~furuse/generics/index.html As always, I have to warn that this is quite experimental and therefore may contain MANY BUGS... And it is based on O'Caml 2.02. This "safe value I/O" facility consists of two primitive functions, export_value and import_value. They can be replacements of the O'Caml's original value I/O functions, output_value and input_value: # export_value;; - : out_channel -> $a -> unit = # import_value;; - : in_channel -> $a = export_value primitive writes an ML value with its encoded type information to the channel. import_value read its value and type information and checks it matches with the current type context. If the type of output value is more general than the expected type, it permits the value importation. Otherwise, it raises an exception: # let oc = open_out_bin "foo.dat" in export_value oc (1,"hello");; - : unit = () It writes out the value (1,"hello") and the fingerprint of its type int * string. The import_value primitive compares this fingerprint with the expected type: # let ic = open_in_bin "foo.dat" in (import_value ic : int * string);; - : int * string = 1, "hello" # let ic = open_in_bin "foo.dat" in (import_value ic : int * float);; - : int * string = 1, "hello" Uncaught exception: Extern.Type_match_failure(...) Programs exchanging values need not to be same. Moreover, you hackers may be able to exchange values safely even between different types, if their type definition structures are isomorphic to each other except differences of their names. For example, these two type definitions have isomorphic: type 'a tree = Branch of 'a tree * 'a tree | Leaf of 'a type 'a arbre = Branche of 'a arbre * 'a arbre | Feuille of 'a The drawback is that your programs must carry the digests of data types (= fingerprints) at run time. This costs some amount of space, but it is usually small compared to the other part. Regards, ----------------------------------------------------------------------- Jun P. Furuse Jun.Furuse@inria.fr ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr