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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id DD3727EE09 for ; Fri, 26 Oct 2012 22:02:10 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloCADHrilDRVd+2m2dsb2JhbABEwk4IIwEBAQEBCAkLCRQngh4BAQEEEgITGQEbHQEDDAYFCw0uIQEBEQEFARwGEwgSAQeHUQEDDwudMGIJA4wwgnaEeQoZJw1ZiHUBBQyKfmcBE4ZaA5QegVWBF4oXgy8WKYQTgVkJFw X-IronPort-AV: E=Sophos;i="4.80,656,1344204000"; d="scan'208";a="160554192" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 Oct 2012 22:02:09 +0200 Received: by mail-ie0-f182.google.com with SMTP id k10so7606991iea.27 for ; Fri, 26 Oct 2012 13:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=8TvpR1gpDzqu1NGRWhooTmJIRzp4nmnBFUKkJWTOJ70=; b=YJxvOzMF28F/Q9R9YqgSivP2UZB0STcOdkaGiRjzzag89aFksT5KsJcs376p7G4r7a Q6fzRBrXa5Y4yzVMalaTvARx1YsE5Np4tAkX6541c6/y3ucCwoL0sIHZpSJH08C51+aI cBXLljp3PhT3MjOSpYi7FTb8HkulRJ+Z2rNLgHASUvOjnNJZ8UOcOrUTohUdaXAfRWaF iK7lJ2kntAnW4m0ciS60VMSgEyW8TR1N/6rR2nRJ8JBrpWHNVKSRCr6aeHyHtVb7FV+p wwzjEVv/dDapN0vNAIJAKISq2TMu805sduoG/yYKIPgqc1FSECFIwk4qBfNAVbMnJbtf AJ/Q== Received: by 10.42.35.136 with SMTP id q8mr20411878icd.11.1351281728455; Fri, 26 Oct 2012 13:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.65.9 with HTTP; Fri, 26 Oct 2012 13:01:28 -0700 (PDT) In-Reply-To: References: <1351280342705@names.co.uk> From: Gabriel Scherer Date: Fri, 26 Oct 2012 22:01:28 +0200 Message-ID: To: "\"Mark\"" Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] accessing the type of a polymorphic parameter Also relevant is this old blog bost by Mat=EDas Giovannini about manual encoding of Haskell type classes (essentially the ('a ops) idea): http://alaska-kamtchatka.blogspot.fr/2009/08/fun-with-type-class.html On Fri, Oct 26, 2012 at 9:58 PM, Gabriel Scherer wrote: > If you can formulate your problems with ('a ops), the module defining > an abstract type t can provide a (t ops) from inside the abstraction > boundary. Handling composite data types is also rather easy, just > provide for example an ('a ops -> 'a list ops) function. > > The runtime type representation idea of Alain can also be extended to > deal with private types, but you need either to pre-plan the required > operation in advance and provide them from inside the abstraction > boundary, or expose the runtime type representation of the abstract > type which lessen encapsulation (but you can hardly do worse than > using Obj.magic in this case). This is present in "ocaml-ty", a > prototype work on runtime type representation by Pierre Chambart and > Gr=E9goire Henry which has been presented during the last OCaml Users > and Developers Meeting back in September. It's experimental work and a > moving target, and comes with a "modification of the language" part > that isn't really the concern here, but you could think of looking at > their work (and providing them feedback!) if you really insist on > making heavy use of ad-hoc polymorphism. > https://gitorious.org/ocaml-ty > > > > On Fri, Oct 26, 2012 at 9:39 PM, "Mark" wro= te: >> Superb, thanks David, Lilian, Gabriel. This may be just about sufficient >> for my purposes. I'll have a play. >> >> As well as predefined OCaml primitive datatypes, what would perfect for = me >> would be the ability to also do newly created abstract datatypes, and >> composite datatypes like lists of strings. Are either of these possible >> with your solutions? >> >> Mark. >> >> on 26/10/12 7:29 PM, David Allsopp wrote: >> >>> ... >>> For this explicit example, you could write: >>> >>> let foo x =3D >>> match Obj.tag (Obj.repr x) with >>> x when x =3D Obj.int_tag -> ... >>> | x when x =3D Obj.string_tag -> ... >>> >>> but this probably isn't what you're after. The type of foo will also be= 'a >>> -> '_b so you won't get any help from the type system in the calling of >> foo. >>> ... >> >> >> on 26/10/12 7:50 PM, Lilian Jean BESSON wr= ote: >> >>> ... >>> In my code "surcharge.ml", the main functions are "typage" : 'a -> >>> string, and "dump" : a' -> string. >>> Examples: >>> #9> Surcharge.typage;; >>> - : 'a -> string =3D >>> #10> Surcharge.typage 4 (* ok *);; >>> - : string =3D "int" >>> #11> Surcharge.typage 8.7 (* ok *);; >>> - : string =3D "float" >>> #12> Surcharge.typage "ok";; (* ok *) >>> - : string =3D "string" >>> #13> Surcharge.typage 'k' (* not ok *);; >>> - : string =3D "int" >>> #14> Surcharge.typage [4] (* not ok *);; >>> - : string =3D "array" >>> #15> Surcharge.typage [|4|];; >>> - : string =3D "array" >>> #16> Surcharge.typage cos (* not ok *);; >>> - : string =3D "unknown" >>> But this function "typage" is very limited : no difference between arra= ys >>> and strings etc... >>> ... >> >> >> on 26/10/12 8:24 PM, Gabriel Scherer wrote: >> >>> ... >>> Long answer: I presume that your implementation works for any type >>> providing some fixed set of operations, but that you wish those >>> operations to be implemented differently for each type. You can define >>> a type ('a ops) describing these operations on the type 'a (as a >>> record of functions for example), and use the polymorphic type ('a -> >>> 'a ops -> foo) instead of ('a -> foo) to write your function. >>> Depending on your specific needs there may be slightly different >>> approaches (using a algebraic representation of runtime types rather >>> than a typeclass-like dictionary), a very general way being described >>> in this blog post by Alain Frisch : >>> http://www.lexifi.com/blog/dynamic-types >>> It could help to have more details on your needs to suggest a better >>> solution. >>> >>> Wrong answer: yes, using Obj.magic you can access the runtime >>> representation of values. You can't distinguish between boolean and >>> integers and the empty list, but worrying about that is for the >>> coward, let's shoot yourself in the foot -- starting by reading the >>> documentation on the representation of OCaml values, chapter >>> "interacting with C" in the manual. >>> ...