From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6CCB97F8BE for ; Mon, 28 Apr 2014 10:13:36 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gdsfh1@gmail.com) identity=pra; client-ip=209.85.223.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gdsfh1@gmail.com"; x-sender="gdsfh1@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gdsfh1@gmail.com designates 209.85.223.176 as permitted sender) identity=mailfrom; client-ip=209.85.223.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gdsfh1@gmail.com"; x-sender="gdsfh1@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f176.google.com) identity=helo; client-ip=209.85.223.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gdsfh1@gmail.com"; x-sender="postmaster@mail-ie0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEBAF8NXlPRVd+wlGdsb2JhbABZhCyCZagGBZl2gQQIFg4BAQEBBwsLCRIqgiUBAQQBIwQZARseAwELBgULDwImAgIiAREBBQEcBog/AQMJCJoRjBBRgw2YHQoZJw1khhQRAQUMgR2EMYgoXoJvgUoEiWuKDoUTkG0YKYRkOoEt X-IPAS-Result: AoEBAF8NXlPRVd+wlGdsb2JhbABZhCyCZagGBZl2gQQIFg4BAQEBBwsLCRIqgiUBAQQBIwQZARseAwELBgULDwImAgIiAREBBQEcBog/AQMJCJoRjBBRgw2YHQoZJw1khhQRAQUMgR2EMYgoXoJvgUoEiWuKDoUTkG0YKYRkOoEt X-IronPort-AV: E=Sophos;i="4.97,942,1389740400"; d="scan'208";a="70674142" Received: from mail-ie0-f176.google.com ([209.85.223.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Apr 2014 10:13:35 +0200 Received: by mail-ie0-f176.google.com with SMTP id rd18so6057709iec.7 for ; Mon, 28 Apr 2014 01:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=slXuDEt0PqM105AuqH/JbfdO3Qf2Cl3bGdgabR8vltg=; b=fE8gueoiD5RpKm3ZrZxNI0AU7q3lX6nSAOY0mLdULTyb4kJjkmcDJdU3I7o2PtyShT j76az+tkWHaGwcCZc3zyfgeJhBiQkbmMGZMRVx2mFoMl0HayT0+PDA85vD6IS26uMaAa cglLpKPzTCTjwLxS2HuSlmxDFUGonG8BDzof6sFpfvic1B096k0xrJCanEU3gD5LOWn/ nREW/iAvazMG1v0Jo60xqPPHCMRTM0sTQuD8+uwT8UNRyH4Qwpy/SbtSgi+Fh6NP1gs3 OM/2Uh97kEYgPdqr2crA3leKvX29v95LgtdYNgnMtdGaZPCaido+gttIFw3Zas7M8F3g SuYA== MIME-Version: 1.0 X-Received: by 10.43.178.197 with SMTP id ox5mr21504998icc.22.1398672814944; Mon, 28 Apr 2014 01:13:34 -0700 (PDT) Received: by 10.43.115.70 with HTTP; Mon, 28 Apr 2014 01:13:34 -0700 (PDT) In-Reply-To: <20140428073625.GA5776@frosties> References: <5356225B.1090305@cryptosense.com> <20140428073625.GA5776@frosties> Date: Mon, 28 Apr 2014 11:13:34 +0300 Message-ID: From: Dmitry Grebeniuk To: Goswin von Brederlow Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Obj.magic for polymorphic identifiers Hello. >> # open Cdt;; >> # let hlist = [ubox ti_int 123; ubox ti_string "qwe"; ubox ti_bool true];; >> val hlist : Cdt.ubox list = >> [{ub_store = ; ub_uti = }; {ub_store = ; ub_uti = }; >> {ub_store = ; ub_uti = }] > > How do you encode a > > type foo = Foo | Bar > > Someone has to implement a ti_foo for it. I do not encode type foo anyhow, if its structure is not needed, like in Romain's example. As for ti_foo, you are right: let ti_foo : foo #ti = new ti_simple "foo" () is enough to box/unbox values of type foo using ti_foo. (Also type name is not needed, but it eases values introspection, so I always use meaningful type names here. Type annotation is not needed too, in most cases.) >> if uti == (ti_string :> uti) then uget_exn ti_string ub else > Here you have to match every possible type, which doesn't scale. It's just Romain's example encoded with my library. Of course this approach doesn't scale, but second piece of code ("show" method) scales well. > Or you limit yourself to structure, which is unsound > for retrieving the original type. Sorry, can't understand what you mean here; but maybe other parts of my reply answer this. > Where is your > > val unbox : type a . uti -> Cdt.ubox -> a > > (which isn't well typed like that) Of course it's not typed. One has to provide "witness" for this operation. Both examples had such "unbox": uget_exn : #tti 'a -> ubox -> 'a So, no magic. But no Obj too! Answering further possible questions: - What if 'a and 'b, where 'a <> 'b, will have the same "runtime type information"? -- It's impossible. ('a and 'b could _look_ different due to type aliases or module abstractions, but they have the same "original type") - What if one creates two distinct "runtime type informations" for given 'a, how will this work? -- It won't work: once a "witness" was used to create ubox, only this "witness" can be used to retrieve typed value. (however I do some kind of "inheritance" on "witnesses" and untyped methods dictionaries that allows me to use some tricks like redefining "show" or "cmp" methods leaving possibility to work with uboxes using different typeinfos, but it's not essential here.)