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 384797FD02 for ; Sun, 3 May 2015 10:41:21 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.213.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.213.175 as permitted sender) identity=mailfrom; client-ip=209.85.213.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-ig0-f175.google.com) identity=helo; client-ip=209.85.213.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ig0-f175.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CxAwDj3UVVlK/VVdFcg19cBYMYtAeOKIIJhgQCgTUHPBABAQEBAQEBEQEBAQEHCwsJHzCEIAEBAQMBEhEdARsSBgUBAwELBgMCCw0NHQICIQEBEQEFAQoSBhMSCQeHdAEDCQgNlH6QXz4xizmBa4J2iB8KGScDClaESAEBAQEBBQEBAQEBAQEBFAEFDosrgk2CNAQHgmiBRQWFPAqQWIRsgVWBYY1dhRYSI4EMCYIIghE8MYJFAQEB X-IPAS-Result: A0CxAwDj3UVVlK/VVdFcg19cBYMYtAeOKIIJhgQCgTUHPBABAQEBAQEBEQEBAQEHCwsJHzCEIAEBAQMBEhEdARsSBgUBAwELBgMCCw0NHQICIQEBEQEFAQoSBhMSCQeHdAEDCQgNlH6QXz4xizmBa4J2iB8KGScDClaESAEBAQEBBQEBAQEBAQEBFAEFDosrgk2CNAQHgmiBRQWFPAqQWIRsgVWBYY1dhRYSI4EMCYIIghE8MYJFAQEB X-IronPort-AV: E=Sophos;i="5.13,359,1427752800"; d="scan'208";a="138691454" Received: from mail-ig0-f175.google.com ([209.85.213.175]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 May 2015 10:41:19 +0200 Received: by igblo3 with SMTP id lo3so63508092igb.0 for ; Sun, 03 May 2015 01:41:18 -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=WxsXxdDjahkjGtrwD/Fki52BvVggNC43G7KmFDglF1Q=; b=Cwbrzt9jHn3Rns9BZ38/VzMgxexkanVFk8AlLWh6n6qAsRiYAne4FbAhD/xO3ub17F ISt0A/O4ckKEIr5PFUcsg32OGdXhHzUSU9GkdyN7bvCHMTQJV5GCEuypyMNKNmHv4Aop KLKet87SlMGu+p157VEjQ7obVi9zNeiBcdWQ2eLoSPIViFzUVUdIPBJb7ASPwbMTcexD w2kjYjz49nULjcxXEvjRv1gDk0hdqgyTmxkoBBKn8HRjAo6RrZ5aqUDF+rSfZVj38NI6 bTJBTONsDxh4sHbdtAyNwYqdKFydaAV4sr6RGwl54TjtWEB8+V4NCw48zVhBhP35TM3X THSg== X-Received: by 10.50.36.66 with SMTP id o2mr6926303igj.16.1430642478307; Sun, 03 May 2015 01:41:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.70.4 with HTTP; Sun, 3 May 2015 01:40:38 -0700 (PDT) In-Reply-To: References: <20150501112114.1C8DFC382A@www1.g3.pair.com> <1430496980.1158661.261513285.08E1920C@webmail.messagingengine.com> <1430498707.1164081.261525093.47AD6B00@webmail.messagingengine.com> <5545384D.40803@mcmaster.ca> <554587C0.1070500@mcmaster.ca> From: Gabriel Scherer Date: Sun, 3 May 2015 10:40:38 +0200 Message-ID: To: =?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?= Cc: Jacques Carette , OCaml Mailing List Content-Type: multipart/alternative; boundary=089e01182e3eb860360515296833 Subject: Re: [Caml-list] Problems with printing MetaOCaml generated code --089e01182e3eb860360515296833 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable .< 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 =3D 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 =3D 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, =C3=96mer Sinan A=C4=9Facan 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 =3D 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 tha= t. > > 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 co= de > 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, =C3=96mer Sinan A=C4=9Facan 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 =3D .< A >. in > >>> and then > >>> print_code std_formatter .< .~stx1 >. ; > >>> > >>> That ought to work as you wish. > >>> > >>> Jacques > >>> > >>> > >>> On 2015-05-02 2:45 PM, =C3=96mer Sinan A=C4=9Facan wrote: > >>>> > >>>> In case anyone's still interested, I produced a very simple example > that > >>>> demonstrates the issue: > >>>> > >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 = ls > >>>> Main.ml Syntax.ml > >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 = cat Syntax.ml > >>>> type stx =3D > >>>> | A > >>>> | B of stx > >>>> | C of (stx * stx) > >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 = cat Main.ml > >>>> open Format > >>>> open Print_code > >>>> open Runcode > >>>> open Syntax > >>>> > >>>> let _ =3D > >>>> let stx1 =3D A in > >>>> let stx2 =3D B A in > >>>> let stx3 =3D 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 >.); > >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 = metaocamlc > Syntax.ml > >>>> -c > >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 = metaocamlc > >>>> Syntax.cmo Main.ml -o main > >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 = ./main > >>>> .<(* CSP stx1 *) Obj.magic 0>. .<(* CSP stx2 *)>. .<(* CSP stx3 > *)>. > >>>> .< > >>>> (* CSP stx1 *) Obj.magic 0>. .<(* CSP stx2 *)>. .<(* CSP stx3 *)= >. > >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 > >>>> > >>>> > >>>> 2015-05-01 12:53 GMT-04:00 =C3=96mer Sinan A=C4=9Facan : > >>>>>> > >>>>>> You can't serialize `eval_ref` as `eval_ref` because that is a loc= al > >>>>>> 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 > --089e01182e3eb860360515296833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
.&l= t; 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 e= xample (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 r= un 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 v= alue of the previous stage (because it is "serializable") can be = transported to the current stage. (One can think of this as a runtime refer= ence 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 t= he local context. Consider:

=C2=A0 print_code (let x =3D 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 n= ot printed).

On the contrary, with:

=C2=A0 lib.ml:
=C2=A0=C2=A0=C2=A0 let x =3D A
=
=C2=A0 main.ml:
=C2=A0=C2= =A0=C2=A0 print_code (let open Lib in .< x >.)

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

On Sun, May 3, 2015 at 5:19= AM, =C3=96mer Sinan A=C4=9Facan <omeragacan@gmail.com> w= rote:
> 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:=

=C2=A0 let stx =3D A in .< stx >.

(Btw, MetaML has explicit `lift` function for this operation, I'm wonde= ring if
there are any differences between MetaML's `lift` and MetaOCaml's i= mplicit
lifting)

> In the context of staging, a variable and its value are radically diff= erent,
> 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 pr= oblem
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 "r= adically
different")

> If you want to persist "named values", then give globally ac= cessible 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 th= at.

Can you explain how is this a "solution"? To rephrase my g= oal one more time: I'm
generating specialized code in runtime, but instead of running it, I want t= o
serialize it so that I can 1) inspect the generated code and make sure I= 9;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 genera= ted
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 diff= erent,
> 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 ac= cessible names
> to these values [which I believe others have already told you].=C2=A0 = If you want
> to persist values, then use my solution or a variant of that.
>
> Jacques
>
>
> On 2015-05-02 9:56 PM, =C3=96mer Sinan A=C4=9Facan wrote:
>>
>> That's not a solution. I should be able to generate some value= s in
>> code generation time and persist them in code values, that's t= he whole
>> point here.
>>
>> 2015-05-02 16:49 GMT-04:00 Jacques Carette <carette@mcmaster.ca>:
>>>
>>> try instead
>>>=C2=A0 =C2=A0 =C2=A0let stx1 =3D .< A >. in
>>> and then
>>>=C2=A0 =C2=A0 =C2=A0print_code std_formatter .< .~stx1 >.= ;
>>>
>>> That ought to work as you wish.
>>>
>>> Jacques
>>>
>>>
>>> On 2015-05-02 2:45 PM, =C3=96mer Sinan A=C4=9Facan wrote:
>>>>
>>>> In case anyone's still interested, I produced a very s= imple example that
>>>> demonstrates the issue:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0=E2=9E=9C=C2=A0 metaocaml_serialization= _issue git:(master) =E2=9C=97 ls
>>>>=C2=A0 =C2=A0 =C2=A0Main.ml=C2=A0 Syntax.ml
>>>>=C2=A0 =C2=A0 =C2=A0=E2=9E=9C=C2=A0 metaocaml_serialization= _issue git:(master) =E2=9C=97 cat Syntax.ml
>>>>=C2=A0 =C2=A0 =C2=A0type stx =3D
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| A
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| B of stx
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| C of (stx * stx)
>>>>=C2=A0 =C2=A0 =C2=A0=E2=9E=9C=C2=A0 metaocaml_serialization= _issue git:(master) =E2=9C=97 cat Main.ml
>>>>=C2=A0 =C2=A0 =C2=A0open Format
>>>>=C2=A0 =C2=A0 =C2=A0open Print_code
>>>>=C2=A0 =C2=A0 =C2=A0open Runcode
>>>>=C2=A0 =C2=A0 =C2=A0open Syntax
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0let _ =3D
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0let stx1 =3D A in
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0let stx2 =3D B A in
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0let stx3 =3D C (A, A) in
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0print_code std_formatter .< s= tx1 >.;
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0print_code std_formatter .< s= tx2 >.;
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0print_code std_formatter .< s= tx3 >.;
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0print_closed_code std_formatter = (close_code .< stx1 >.);
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0print_closed_code std_formatter = (close_code .< stx2 >.);
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0print_closed_code std_formatter = (close_code .< stx3 >.);
>>>>=C2=A0 =C2=A0 =C2=A0=E2=9E=9C=C2=A0 metaocaml_serialization= _issue git:(master) =E2=9C=97 metaocamlc Syntax.ml
>>>> -c
>>>>=C2=A0 =C2=A0 =C2=A0=E2=9E=9C=C2=A0 metaocaml_serialization= _issue git:(master) =E2=9C=97 metaocamlc
>>>> Syntax.cmo Main.ml -o main
>>>>=C2=A0 =C2=A0 =C2=A0=E2=9E=9C=C2=A0 metaocaml_serialization= _issue git:(master) =E2=9C=97 ./main
>>>>=C2=A0 =C2=A0 =C2=A0.<(* CSP stx1 *) Obj.magic 0>. .&= lt;(* CSP stx2 *)>. .<(* CSP stx3 *)>.
>>>> .<
>>>>=C2=A0 =C2=A0 =C2=A0(* CSP stx1 *) Obj.magic 0>. .<(*= CSP stx2 *)>. .<(* CSP stx3 *)>.
>>>>=C2=A0 =C2=A0 =C2=A0=E2=9E=9C=C2=A0 metaocaml_serialization= _issue git:(master) =E2=9C=97
>>>>
>>>>
>>>> 2015-05-01 12:53 GMT-04:00 =C3=96mer Sinan A=C4=9Facan <= ;omeragacan@gmail.com>:
>>>>>>
>>>>>> You can't serialize `eval_ref` as `eval_ref` b= ecause 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 identifie= r 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 prin= ting this:
>>>>>
>>>>> .<Unlambda.eval_ref (* CSP p' *) []>.
>>>>>
>>>>> My main question is that it should serialize p' he= re, but it doesn't.
>>>>> I'm
>>>>> trying to understand why.
>>>
>>>
>

--
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
--089e01182e3eb860360515296833--