Re: [Caml-list] Problems with printing MetaOCaml generated code

[Gabriel Scherer <gabriel.scherer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7369 bytes --]

.< x >. represents a piece of code that is just the variable x. Printed to
a string, it is "x". (Regardless of the definition of x, for example (A))

.< ~x >. represents a piece of code that is contained in the value of the
variable x. For example, if the value of x is .< A >. , then the string
representation of .< ~x >. would be "A".

When running code in the same MetaOCaml program, you can use them in
closely related ways: running .< f ~x >. will run the function f with the
value of x, A, but running .< f x >. will also work because x acts here as
a reference to a previous stage, and the value of the previous stage
(because it is "serializable") can be transported to the current stage.
(One can think of this as a runtime reference to a compile-time value or
computation)

When printing the code, they are fundamentally different, because indeed
the variable .< x >. may not mean anything in printed code if it is only
meaningful in the local context. Consider:

  print_code (let x = A in .< x >.)

what could the program print here? "x" would be wrong, because the receiver
of the code has no way to know what "x" means (the declaration of x is at
the previous stage, it is not printed).

On the contrary, with:

  lib.ml:
    let x = A

  main.ml:
    print_code (let open Lib in .< x >.)

there, because x is a reference that *can be named* at the toplevel of an
OCaml program, you can print something, namely "Lib.x".

On Sun, May 3, 2015 at 5:19 AM, Ömer Sinan Ağacan <omeragacan@gmail.com>
wrote:

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

[-- Attachment #2: Type: text/html, Size: 10063 bytes --]