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