Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jeremy Yallop <yallop@gmail.com>
To: Oleg Kiselyov <oleg@okmij.org>
Cc: "Ömer Sinan Ağacan" <omeragacan@gmail.com>,
	"Caml List" <caml-list@inria.fr>
Subject: Re: [Caml-list] Problems with printing MetaOCaml generated code
Date: Wed, 6 May 2015 16:58:03 +0100	[thread overview]
Message-ID: <CAAxsn=HA+U903wCvHSZWC5HdY61PrtEhXge4nT_jvOY4hkuVOg@mail.gmail.com> (raw)
In-Reply-To: <20150506095012.91063C382B@www1.g3.pair.com>

On 6 May 2015 at 10:50,  <oleg@okmij.org> 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
>         .<fun u ->  x>.
> write
>         .<fun u -> .~(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 = .<Stx.B Stx.A>.

  # 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.

  reply	other threads:[~2015-05-06 15:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-30 18:36 Ömer Sinan Ağacan
2015-04-30 19:52 ` Jacques Carette
2015-04-30 20:25   ` Ömer Sinan Ağacan
2015-04-30 20:57     ` Ömer Sinan Ağacan
2015-04-30 21:35       ` Jeremy Yallop
2015-05-01 11:21       ` oleg
2015-05-01 14:34         ` Ömer Sinan Ağacan
2015-05-01 16:16           ` Leo White
2015-05-01 16:41             ` Ömer Sinan Ağacan
2015-05-01 16:45               ` Leo White
2015-05-01 16:53                 ` Ömer Sinan Ağacan
2015-05-02 18:45                   ` Ömer Sinan Ağacan
2015-05-02 20:49                     ` Jacques Carette
2015-05-03  1:56                       ` Ömer Sinan Ağacan
2015-05-03  2:28                         ` Jacques Carette
2015-05-03  3:19                           ` Ömer Sinan Ağacan
2015-05-03  8:40                             ` Gabriel Scherer
2015-05-03 14:28                               ` Ömer Sinan Ağacan
2015-05-03 15:24                                 ` Leo White
2015-05-03 15:50                                   ` Ömer Sinan Ağacan
2015-05-06  9:50           ` oleg
2015-05-06 15:58             ` Jeremy Yallop [this message]
2015-05-06 16:45               ` Yotam Barnoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAxsn=HA+U903wCvHSZWC5HdY61PrtEhXge4nT_jvOY4hkuVOg@mail.gmail.com' \
    --to=yallop@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=oleg@okmij.org \
    --cc=omeragacan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox