From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 3320FBB84 for ; Sat, 29 Nov 2008 18:01:29 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlABAJQEMUlIDtyYkGdsb2JhbACTCj4BAQEBCQkMBxEDrj2BAoo8AQMBA4J6 X-IronPort-AV: E=Sophos;i="4.33,687,1220220000"; d="scan'208";a="17768379" Received: from fg-out-1718.google.com ([72.14.220.152]) by mail2-smtp-roc.national.inria.fr with ESMTP; 29 Nov 2008 18:01:18 +0100 Received: by fg-out-1718.google.com with SMTP id l27so1270290fgb.43 for ; Sat, 29 Nov 2008 09:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=y2N6kaaxt2Avu3lhw4E0JT2beQRJtzFEQX3rI79hsEg=; b=omPjToyHSAA2hgEIhcOtO6vtqiKkFqqUsi45og0fDDUnguKQryilBwPg6y8QRmyJlX kLmTpRA0DVA2fiiM5g/RfRz/CWu1h+xKUv4o8u0Owbuld5ve+NznzC37lMTZIX3eU8KW EpfVx4cut6OqNExJ1JJbrtkLS56nV3Fd2LjS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NQlloa4IyFzBa/0oTjOBHvyUyEJarAkvQLegYcd2SwTi7d8KjOxJBZEXzdm49jZIIM i1ztPvvj+dJUP/G3xnaAtxvuBey/q5yqm+Q4kph/GBvsNMOtq1tS+MD4WQV212R1/qbT VoWrqDoUOrF7AgdGBKK2h3wjqiItsnpV6JU1w= Received: by 10.86.31.18 with SMTP id e18mr5712516fge.72.1227978077653; Sat, 29 Nov 2008 09:01:17 -0800 (PST) Received: by 10.86.2.17 with HTTP; Sat, 29 Nov 2008 09:01:17 -0800 (PST) Message-ID: <9d3ec8300811290901l4d2596a9mef88e5f0f4bcb956@mail.gmail.com> Date: Sat, 29 Nov 2008 12:01:17 -0500 From: "Till Varoquaux" To: "Dario Teixeira" Subject: Re: [Caml-list] Issues with Sexplib (#1) Cc: caml-list@yquem.inria.fr In-Reply-To: <110907.37517.qm@web111509.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <110907.37517.qm@web111509.mail.gq1.yahoo.com> X-Spam: no; 0.00; bug:01 camlp:01 sexp:01 foobar:01 foobar:01 constructors:01 constructors:01 sig:01 sexp:01 val:01 val:01 struct:01 endline:01 compile-time:01 runtime:01 This is not really a bug; I'd qualify this as an "undesirable" feature: sexplib erases type information; for instance the representation of None* will always be the same and therefore will be desexpable to any other option type. You may also note that some other type have compatible representations. In practice it would be really hard for a camlp4 extension to keep track of types. In you case you could use custom converters and save the phantom type in the sexp. Till *well more or less: you could be using a custom converter or an old version of sexplib On Sat, Nov 29, 2008 at 11:40 AM, Dario Teixeira wrote: > Hi, > > I have found a couple of issues with Sexplib/Type-conv. I am not sure they > are bugs or features, but to me they come across as unexpected, regardless. > In this message I'll report the first one; the second follows momentarily. > > Consider the Foobar module defined below. It uses a phantom type to annotate > values of type Foobar.t, defined recursively. The idea is that constructors > A and C are deemed "basic" while B and D are "complex". Functions make_basic > and make_complex are used to "freeze" the structure. Because the complex > phantom value propagates across a structure, one cannot apply make_basic to > a structure that uses any of the complex constructors. On the other hand, > make_complex can be applied to any structure. > > module Foobar: > sig > type foobar_t = > | A > | B > | C of foobar_t > | D of foobar_t > with sexp > > type basic_t = [ `Basic ] with sexp > type complex_t = [ `Complex ] with sexp > > type 'a t with sexp > > val make_a: unit -> [> `Basic ] t > val make_b: unit -> [> `Complex ] t > val make_c: 'a t -> 'a t > val make_d: 'a t -> [> `Complex ] t > > val make_basic: [< `Basic ] t -> [ `Basic ] t > val make_complex: [< `Basic | `Complex ] t -> [ `Complex ] t > end = > struct > type foobar_t = > | A > | B > | C of foobar_t > | D of foobar_t > with sexp > > type basic_t = [ `Basic ] with sexp > type complex_t = [`Complex ] with sexp > > type 'a t = foobar_t with sexp > > let make_a () = A > let make_b () = B > let make_c foobar = C foobar > let make_d foobar = D foobar > > let make_basic x = x > let make_complex x = x > end > > > So far so good; now consider the code below, which serialises and then > unserialises a value of type Foobar.t. Note how a "complex" structure > can be unserialised as "basic" without any consequences. Therefore, the > (de)serialisation process can be used to circumvent the restrictions imposed > by the phantom type. > > open Foobar > > let foobar = make_complex (make_c (make_b ())) > > let doc = > let sexp = sexp_of_t sexp_of_complex_t foobar in > let str = Sexplib.Sexp.to_string_hum sexp > in print_endline str; > let sexp2 = Sexplib.Sexp.of_string str in > let doc = t_of_sexp basic_t_of_sexp sexp2 > in doc > > > The resulting types are: > > val foobar : Document.Foobar.complex_t Document.Foobar.t (* Complex *) > val doc : Document.Foobar.basic_t Document.Foobar.t (* Basic *) > > I understand that phantom types have only a compile-time significance, > with no runtime expression at all (hence their name). Therefore, it's not > altogether surprising that the S-expression builder would simply ignore them. > Still, is there a way to make them explicit in the serialised data, such > that the unserialiser would cause a runtime error in the above example? > Note that the serialiser is already passed sexp_of_complex_t though it > doesn't seem to put it into any actual use. > > Thanks for your time! > Best regards, > Dario Teixeira > > > > > > _______________________________________________ > 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 >