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 6CB1B7FD02 for ; Wed, 6 May 2015 18:46:07 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.160.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.160.172 as permitted sender) identity=mailfrom; client-ip=209.85.160.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@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-yk0-f172.google.com) identity=helo; client-ip=209.85.160.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-yk0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxAgAsREpVm6ygVdFcg19cBYMYs3OOKjOBVoYFAoEfBzkTAQEBAQEBAREBAQEBAQYLCwkhLoQgAQEBAwESEQQZARsSCwEDAQsGAwILDQ0dAgIhAQERAQUBChIGExIQh3QBAwoIDZRbkGA+MYs4gWuCd4kiChknAwpXhCwBAQEBAQEBAwEBAQEBAQEBARMBBQ6LK4JNgjQEB4JogUUFhTwKii6GRYRvgVWBJD2NGFaDFoIJEiOBDAmENCIxgkUBAQE X-IPAS-Result: A0DxAgAsREpVm6ygVdFcg19cBYMYs3OOKjOBVoYFAoEfBzkTAQEBAQEBAREBAQEBAQYLCwkhLoQgAQEBAwESEQQZARsSCwEDAQsGAwILDQ0dAgIhAQERAQUBChIGExIQh3QBAwoIDZRbkGA+MYs4gWuCd4kiChknAwpXhCwBAQEBAQEBAwEBAQEBAQEBARMBBQ6LK4JNgjQEB4JogUUFhTwKii6GRYRvgVWBJD2NGFaDFoIJEiOBDAmENCIxgkUBAQE X-IronPort-AV: E=Sophos;i="5.13,380,1427752800"; d="scan'208";a="139268343" Received: from mail-yk0-f172.google.com ([209.85.160.172]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 May 2015 18:46:06 +0200 Received: by ykep21 with SMTP id p21so4082846yke.3 for ; Wed, 06 May 2015 09:46:05 -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; bh=ZLUnsfYqm0PKW3dSJmcA1bmMcY2S07MLPgpxSz4HEEk=; b=DtHi84tMOhycPb6GKkhR81yiIjLnvZKCLCSRg1L58l+VMDJNgwvFwFzkGvek4Jmei7 6N21vuKVkCUowzE7IyCsHeENrNYWTbENTC8AmUK6eJbDKE8h0Z0mFAN0f2JfY9nLNlFs XHlw0F9va8cHKrjs4+8KW0G1+QyPqJ3LqLPj5qqB2aLyHJ78125oN83Ou2w9KWRkr2aD PIsYMcBtmo23WjCqXnUsNTE4G3hInBQ6tBLVi8s/BVp9L7c4JASRSAhKMdSd8ff5hs2H crWjFi0kbf21AuNGg92DhNa3zoRM7NeoaG8VpkKQ0Xaz18rY17fa1E3P2yIOeDb6x89J sCdA== X-Received: by 10.236.38.231 with SMTP id a67mr22693863yhb.152.1430930765141; Wed, 06 May 2015 09:46:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.43.132 with HTTP; Wed, 6 May 2015 09:45:44 -0700 (PDT) In-Reply-To: References: <20150506095012.91063C382B@www1.g3.pair.com> From: Yotam Barnoy Date: Wed, 6 May 2015 12:45:44 -0400 Message-ID: To: Jeremy Yallop Cc: Oleg Kiselyov , =?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?= , Caml List Content-Type: multipart/alternative; boundary=089e01537d8cf45d0005156c87b6 Subject: Re: [Caml-list] Problems with printing MetaOCaml generated code --089e01537d8cf45d0005156c87b6 Content-Type: text/plain; charset=UTF-8 Mind blown. Let's just call this branch... hmm, I dunno, how about 'OCaml 5'? Sorry for the noise. On Wed, May 6, 2015 at 11:58 AM, Jeremy Yallop wrote: > 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. > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --089e01537d8cf45d0005156c87b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mind blown.

Let's just call this br= anch... hmm, I dunno, how about 'OCaml 5'?

Sorry for the noise.

On Wed, May 6, 2015 at 11:58 AM, Jeremy Yallop <yallop@g= mail.com> wrote:
On 6 May 2015 at 10:50,=C2=A0 <oleg@okmij.org> wrote:
> Of course MetaOCaml serialization can be improved. What I'd like t= o
> stress is that you don't have to wait for the improvement. You can=
> always, instead of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.<fun u ->=C2=A0 x>.
> write
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.<fun u -> .~(mylift x)>.
> where
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mylift : 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 combi= nes
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":

=C2=A0 module type CSP =3D
=C2=A0 =C2=A0sig
=C2=A0 =C2=A0 =C2=A0type t
=C2=A0 =C2=A0 =C2=A0val lift : t -> t code
=C2=A0 end

together with a top-level function that dispatches to the appropriate insta= nce

=C2=A0 let csp (implicit C: CSP) (x : C.t) =3D C.lift x

and instances of CSP for each type of interest.=C2=A0 Here's an instanc= e
for the stx type from earlier in the thread:

=C2=A0 implicit module CSP_stx : CSP with type t =3D stx =3D
=C2=A0 struct
=C2=A0 =C2=A0 type t =3D stx

=C2=A0 =C2=A0 let rec lift : stx -> stx code =3D function
=C2=A0 =C2=A0 =C2=A0 | A -> .< A >.
=C2=A0 =C2=A0 =C2=A0 | B s -> .< B .~ (lift s) >.
=C2=A0 =C2=A0 =C2=A0 | C (s1, s2) -> .< C ( .~(lift s1), .~(lift s2) = ) >.
=C2=A0 =C2=A0end

and here's a parameterised instance for lists that makes it possible
to persist lists of any persistable element type:

=C2=A0 implicit functor CSP_list(C: CSP) : CSP with type t =3D C.t list =3D=
=C2=A0 struct
=C2=A0 =C2=A0 type t =3D C.t list

=C2=A0 =C2=A0 let rec lift : C.t list -> C.t list code =3D function
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [] -> .< [] >.
=C2=A0 =C2=A0 =C2=A0 | x :: xs -> .< .~(csp x) :: .~(lift xs) >. =C2=A0 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.):

=C2=A0 =C2=A0# let ba =3D B A in .< .~(csp ba) >.;;
=C2=A0 =C2=A0- : stx code =3D .<Stx.B Stx.A>.

=C2=A0 # let l =3D [A; B A] in .< .~(csp l) >.;;
=C2=A0 - : stx list code =3D .<[Stx.A; Stx.B Stx.A]>.

=C2=A0 # let ll =3D [[A; B A]] and ba =3D B A in .< .~(csp ll), .~(csp b= a) >.;;
=C2=A0 - : (stx list list * stx) code =3D .<([[Stx.A; Stx.B Stx.A]], (St= x.B Stx.A))>.

It's easy to imagine having the csp function built in to MetaOCaml, so<= br> that we could write .< x >.=C2=A0 (or some similarly convenient synta= x) to
mean .< .~(csp x) >...

You can try out the switch with OPAM in the usual way:

=C2=A0 =C2=A0opam update
=C2=A0 =C2=A0opam switch 4.02.1+modular-implicits-ber
=C2=A0 =C2=A0eval `opam config env`

Jeremy.

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--089e01537d8cf45d0005156c87b6--