caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Ömer Sinan Ağacan" <omeragacan@gmail.com>
To: Jacques Carette <carette@mcmaster.ca>
Cc: OCaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Problems with printing MetaOCaml generated code
Date: Sat, 2 May 2015 23:19:42 -0400	[thread overview]
Message-ID: <CAMQQO3k5eVZ_tyHmCm5ncW-LNsHip8yU5j6cFSx=XxUA6yuJKw@mail.gmail.com> (raw)
In-Reply-To: <554587C0.1070500@mcmaster.ca>

> But that's the whole point: you are not persisting a value, you are
> persisting a local variable.

Can you explain what's wrong with that? I'm making sure that the local
variables I'm trying to persist are persistable, as in my last example:

  let stx = A in .< stx >.

(Btw, MetaML has explicit `lift` function for this operation, I'm wondering if
there are any differences between MetaML's `lift` and MetaOCaml's implicit
lifting)

> In the context of staging, a variable and its value are radically different,
> unlike in the traditional functional programming context, where this
> difference can be safely and harmlessly blurred.

I understand that code values are similar to closures in some ways, for example
they capture some variables, and they're not always serializable. My problem
here is that they're almost never serializable in the case of MetaOCaml. It
even fails to serialize a code object that just holds a single constructor for
a simple type with one constructor, for example.

(It'd be really great if you could elaborate on how they're "radically
different")

> If you want to persist "named values", then give globally accessible names to
> these values [which I believe others have already told you].

...

> If you want to persist values, then use my solution or a variant of that.

Can you explain how is this a "solution"? To rephrase my goal one more time: I'm
generating specialized code in runtime, but instead of running it, I want to
serialize it so that I can 1) inspect the generated code and make sure I'm
really doing the optimizations I'm expecting to do 2) I can compile my code
separately. But MetaOCaml is just refusing to show data values in my generated
code.

I started to feel like the story of MetaOCaml serialization as described in
manual's "Many ways to run the code" section is just wrong.

2015-05-02 22:28 GMT-04:00 Jacques Carette <carette@mcmaster.ca>:
> But that's the whole point: you are not persisting a value, you are
> persisting a local variable.
>
> In the context of staging, a variable and its value are radically different,
> unlike in the traditional functional programming context, where this
> difference can be safely and harmlessly blurred.
>
> If you want to persist "named values", then give globally accessible names
> to these values [which I believe others have already told you].  If you want
> to persist values, then use my solution or a variant of that.
>
> Jacques
>
>
> On 2015-05-02 9:56 PM, Ömer Sinan Ağacan wrote:
>>
>> That's not a solution. I should be able to generate some values in
>> code generation time and persist them in code values, that's the whole
>> point here.
>>
>> 2015-05-02 16:49 GMT-04:00 Jacques Carette <carette@mcmaster.ca>:
>>>
>>> try instead
>>>     let stx1 = .< A >. in
>>> and then
>>>     print_code std_formatter .< .~stx1 >. ;
>>>
>>> That ought to work as you wish.
>>>
>>> Jacques
>>>
>>>
>>> On 2015-05-02 2:45 PM, Ömer Sinan Ağacan wrote:
>>>>
>>>> In case anyone's still interested, I produced a very simple example that
>>>> demonstrates the issue:
>>>>
>>>>     ➜  metaocaml_serialization_issue git:(master) ✗ ls
>>>>     Main.ml  Syntax.ml
>>>>     ➜  metaocaml_serialization_issue git:(master) ✗ cat Syntax.ml
>>>>     type stx =
>>>>       | A
>>>>       | B of stx
>>>>       | C of (stx * stx)
>>>>     ➜  metaocaml_serialization_issue git:(master) ✗ cat Main.ml
>>>>     open Format
>>>>     open Print_code
>>>>     open Runcode
>>>>     open Syntax
>>>>
>>>>     let _ =
>>>>       let stx1 = A in
>>>>       let stx2 = B A in
>>>>       let stx3 = C (A, A) in
>>>>
>>>>       print_code std_formatter .< stx1 >.;
>>>>       print_code std_formatter .< stx2 >.;
>>>>       print_code std_formatter .< stx3 >.;
>>>>
>>>>       print_closed_code std_formatter (close_code .< stx1 >.);
>>>>       print_closed_code std_formatter (close_code .< stx2 >.);
>>>>       print_closed_code std_formatter (close_code .< stx3 >.);
>>>>     ➜  metaocaml_serialization_issue git:(master) ✗ metaocamlc Syntax.ml
>>>> -c
>>>>     ➜  metaocaml_serialization_issue git:(master) ✗ metaocamlc
>>>> Syntax.cmo Main.ml -o main
>>>>     ➜  metaocaml_serialization_issue git:(master) ✗ ./main
>>>>     .<(* CSP stx1 *) Obj.magic 0>. .<(* CSP stx2 *)>. .<(* CSP stx3 *)>.
>>>> .<
>>>>     (* CSP stx1 *) Obj.magic 0>. .<(* CSP stx2 *)>. .<(* CSP stx3 *)>.
>>>>     ➜  metaocaml_serialization_issue git:(master) ✗
>>>>
>>>>
>>>> 2015-05-01 12:53 GMT-04:00 Ömer Sinan Ağacan <omeragacan@gmail.com>:
>>>>>>
>>>>>> You can't serialize `eval_ref` as `eval_ref` because that is a local
>>>>>> identifier. If you print out `eval_ref` into some other ml file and
>>>>>> compiler
>>>>>> it, it is going to give an "Unbound identifier eval_ref" error.
>>>>>
>>>>> That's true. Just to make sure and make the output more clear, I moved
>>>>> the
>>>>> relevant code to another module, and now it's printing this:
>>>>>
>>>>> .<Unlambda.eval_ref (* CSP p' *) []>.
>>>>>
>>>>> My main question is that it should serialize p' here, but it doesn't.
>>>>> I'm
>>>>> trying to understand why.
>>>
>>>
>

  reply	other threads:[~2015-05-03  3:20 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 [this message]
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
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='CAMQQO3k5eVZ_tyHmCm5ncW-LNsHip8yU5j6cFSx=XxUA6yuJKw@mail.gmail.com' \
    --to=omeragacan@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=carette@mcmaster.ca \
    /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;
as well as URLs for NNTP newsgroup(s).