From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 39C4E7FD02 for ; Wed, 6 May 2015 17:58:05 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yallop@gmail.com) identity=pra; client-ip=209.85.192.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="yallop@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yallop@gmail.com designates 209.85.192.52 as permitted sender) identity=mailfrom; client-ip=209.85.192.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="yallop@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-qg0-f52.google.com) identity=helo; client-ip=209.85.192.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="postmaster@mail-qg0-f52.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DeAQCHOUpVmzTAVdFchDsFgxjCRwmHWwKBHwc4FAEBAQEBAQERAQEBAQEGCwsJIS6EIQEBBBIRBBkBGx0BAwwGBQsNAgImAgIiAREBBQEcBhMIGod0AQMSpT8+MYs4gWuCd4kmChknDVeERgEBAQEGAQEBAQEXAQUOgROKGIUFB4JogUUFnH2BJI1Vg2yCCRIjgQwJhBk9MYJFAQEB X-IPAS-Result: A0DeAQCHOUpVmzTAVdFchDsFgxjCRwmHWwKBHwc4FAEBAQEBAQERAQEBAQEGCwsJIS6EIQEBBBIRBBkBGx0BAwwGBQsNAgImAgIiAREBBQEcBhMIGod0AQMSpT8+MYs4gWuCd4kmChknDVeERgEBAQEGAQEBAQEXAQUOgROKGIUFB4JogUUFnH2BJI1Vg2yCCRIjgQwJhBk9MYJFAQEB X-IronPort-AV: E=Sophos;i="5.13,380,1427752800"; d="scan'208";a="139261886" Received: from mail-qg0-f52.google.com ([209.85.192.52]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 May 2015 17:58:04 +0200 Received: by qgej70 with SMTP id j70so6809047qge.2 for ; Wed, 06 May 2015 08:58:03 -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 :cc:content-type; bh=DvXsu0KlIrc5H7XuDEf6TicRdH3MYinm9ho398LqJMg=; b=cSN4lrd46dAXM9k9PqEpsW3kbHUkhjlbhBT9KgVeaUIqkn2momjF1D2JN9Ax6jeIzi /59yT288T1uTuoJkTc1dT6NA2zYTB9JeW/+FFGdgsQMC8a/GTRdYXHvlTkjE7NDCflhX z/AVlm9lO1+eUww6h/dMH7xRrZBbUpwZIJuepLULl2tftES//JbOTj2sgDzaFoUQseik 7gPp0uhUm3l9NLv9JYovC8qsKqjpPsfPn0AcutVSTXBcoY4b8DPF5T2ZcCxnp5d+rpT7 h6b0mQf42Cv+e2vzpkPYwvVrJYVgmlniQkKAIynIaW23abv4Lu8NUUx1Bosnnw+eBmON 2+JQ== MIME-Version: 1.0 X-Received: by 10.140.108.201 with SMTP id j67mr40205476qgf.79.1430927883510; Wed, 06 May 2015 08:58:03 -0700 (PDT) Received: by 10.229.40.7 with HTTP; Wed, 6 May 2015 08:58:03 -0700 (PDT) In-Reply-To: <20150506095012.91063C382B@www1.g3.pair.com> References: <20150506095012.91063C382B@www1.g3.pair.com> Date: Wed, 6 May 2015 16:58:03 +0100 Message-ID: From: Jeremy Yallop To: Oleg Kiselyov Cc: =?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?= , Caml List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Problems with printing MetaOCaml generated code On 6 May 2015 at 10:50, wrote: > Of course MetaOCaml serialization can be improved. What I'd like to > stress is that you don't have to wait for the improvement. You can > always, instead of > . x>. > write > . .~(mylift x)>. > where > mylift : t -> t code > is *your* function that does whatever _you_ like it to do at that > particular type t (it should still produce something of the type (t > code)). > > If some particular mylift functions turn out popular, they can be > added to MetaOCaml, to save everyone trouble writing them. > > And I generally agree with Leo that this implicit lifting is > baroque. At present I'm not sure if requiring the explicit lifting is > too much of a burden. I'm sure that with modular implicits, it won't > be. I've just pushed an OPAM switch for an OCaml compiler that combines the MetaOCaml and modular implicits patches, making it possible to experiment with explicit user-defined polymorphic CSP. For example, you might define a signature, CSP, for "things that can be persisted": module type CSP = sig type t val lift : t -> t code end together with a top-level function that dispatches to the appropriate instance let csp (implicit C: CSP) (x : C.t) = C.lift x and instances of CSP for each type of interest. Here's an instance for the stx type from earlier in the thread: implicit module CSP_stx : CSP with type t = stx = struct type t = stx let rec lift : stx -> stx code = function | A -> .< A >. | B s -> .< B .~ (lift s) >. | C (s1, s2) -> .< C ( .~(lift s1), .~(lift s2) ) >. end and here's a parameterised instance for lists that makes it possible to persist lists of any persistable element type: implicit functor CSP_list(C: CSP) : CSP with type t = C.t list = struct type t = C.t list let rec lift : C.t list -> C.t list code = function [] -> .< [] >. | x :: xs -> .< .~(csp x) :: .~(lift xs) >. end These two instances make it possible to use the CSP function to persist stx values, or lists of stx values, or lists of lists of stx values (etc.): # let ba = B A in .< .~(csp ba) >.;; - : stx code = .. # let l = [A; B A] in .< .~(csp l) >.;; - : stx list code = .<[Stx.A; Stx.B Stx.A]>. # let ll = [[A; B A]] and ba = B A in .< .~(csp ll), .~(csp ba) >.;; - : (stx list list * stx) code = .<([[Stx.A; Stx.B Stx.A]], (Stx.B Stx.A))>. It's easy to imagine having the csp function built in to MetaOCaml, so that we could write .< x >. (or some similarly convenient syntax) to mean .< .~(csp x) >... You can try out the switch with OPAM in the usual way: opam update opam switch 4.02.1+modular-implicits-ber eval `opam config env` Jeremy.