From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 DA18A7FD02 for ; Sun, 3 May 2015 16:29:20 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of omeragacan@gmail.com) identity=pra; client-ip=74.125.82.50; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="omeragacan@gmail.com"; x-sender="omeragacan@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of omeragacan@gmail.com designates 74.125.82.50 as permitted sender) identity=mailfrom; client-ip=74.125.82.50; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="omeragacan@gmail.com"; x-sender="omeragacan@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-wg0-f50.google.com) identity=helo; client-ip=74.125.82.50; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="omeragacan@gmail.com"; x-sender="postmaster@mail-wg0-f50.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B4AwBNMEZVlDJSfUpcgys0XAWDGLQHkDGGBAKBNgc8EAEBAQEBAQERAQEBAQcLCwkfMIQhAQEEEhEdARsSBgUBAwELBgULDQICCR0CAiEBAREBBQEKEgYTEgkHh3QBAxENpUY+MYs5gWuCdogbChknAwpWhEgBAQEBAQEEAQEBAQEBARUBBQ6BE4oYgk2CBTMHgmiBRQWFPAqQWIRsgVWBJD2NXYMOgggSI4EMCYIIIhyBbSIxgkUBAQE X-IPAS-Result: A0B4AwBNMEZVlDJSfUpcgys0XAWDGLQHkDGGBAKBNgc8EAEBAQEBAQERAQEBAQcLCwkfMIQhAQEEEhEdARsSBgUBAwELBgULDQICCR0CAiEBAREBBQEKEgYTEgkHh3QBAxENpUY+MYs5gWuCdogbChknAwpWhEgBAQEBAQEEAQEBAQEBARUBBQ6BE4oYgk2CBTMHgmiBRQWFPAqQWIRsgVWBJD2NXYMOgggSI4EMCYIIIhyBbSIxgkUBAQE X-IronPort-AV: E=Sophos;i="5.13,360,1427752800"; d="scan'208";a="138720270" Received: from mail-wg0-f50.google.com ([74.125.82.50]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 May 2015 16:29:19 +0200 Received: by wgyo15 with SMTP id o15so128492430wgy.2 for ; Sun, 03 May 2015 07:29:19 -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:content-transfer-encoding; bh=zWpVAdz54JzRxq+P4dbUwvhelViV1BiQ3z4tB+72SMc=; b=O4BkdlYHLHb2Z/ym9dOz3/s3DZWwo5r4MieqHH9zg4D+wqgLPMgi5s873uJyzcl3YV oh/dJZ/EJA3q/6duENA4UzNwoAwiNXpM8AxGbT3P2LyRQ8VgAO5bS5DxZjCzO8SeXcOg XEOoT5IyqSx5vSOY4eRW0Mp4G6tJrfUA+OLfsQvJhEq8/VweP5QBnhGFTQxW+Z/3Ejlz dxtLxxaEA3Z4TVCd/QPVL/F/jvJH9HJldRUzY+LvJlxMlQhSWxsES8dlLI8OSwdHgZg1 6DchCYaS7nx6EdKpbYWSYnM/1wG8DA2lcQK85zbIscvV0LPksc7BGKLvgLtXJtLPcV4T nChw== X-Received: by 10.194.47.231 with SMTP id g7mr33212240wjn.140.1430663359702; Sun, 03 May 2015 07:29:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.187.212 with HTTP; Sun, 3 May 2015 07:28:39 -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: =?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?= Date: Sun, 3 May 2015 10:28:39 -0400 Message-ID: To: Gabriel Scherer Cc: Jacques Carette , OCaml Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Problems with printing MetaOCaml generated code > .< x >. represents a piece of code that is just the variable x. Printed t= o a > string, it is "x". (Regardless of the definition of x, for example (A)) I don't think this is true, as far as I can see MetaOCaml doesn't have open= code values that are only runnable in environments that bind free variables in t= he code. # ..;; Error: Unbound value a # let a =3D 1 in ..;; - : int code =3D .<1>. In this example `..` didn't mean a code that is just the variable `a`, instead, `a` is lifted in code and code is now `.<1>.`. I think this automatic lifting is why MetaOCaml doesn't have explicit "lift" operation like MetaML does: variables bound in the environment automatically lifted, so no open code values are possible. > 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 receiv= er > of the code has no way to know what "x" means (the declaration of x is at > the previous stage, it is not printed). That's exactly what I'm trying to ask here... People are trying to explain = that this should be printed as "A": print_code (let x =3D .< A >. in .< .~ x >.); But this shouldn't: print_code (let x =3D A in .< x >.); This doesn't make sense at all. In your example you just said that "x would= be wrong, because receiver of the code has no way to know what x means". Here = the code works like a closure, it captures `x`, but when it comes to printing, = it just prints `CSP value x` instead of printing the value of it, which is completely serializable, indeed it serializes it in the first case. Also, note that if the code is only printed in the first case, then it's impossible to print anything. Because at some point I have to lift some val= ues in my code values, but then I'm losing the ability to print anyway. Example: let stx =3D B A in let c =3D .< stc >. in print_code .< .~ c >.;; Prints .< (* CSP stx *) >. . So once you lift something to code values, you= lose the ability to print. 2015-05-03 4:40 GMT-04:00 Gabriel Scherer : > .< x >. represents a piece of code that is just the variable x. Printed t= o 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 clos= ely > 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 (becau= se > 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 computati= on) > > 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 receiv= er > 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 implic= it >> 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 construct= or >> 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, =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 >> >>>>>> local >> >>>>>> identifier. If you print out `eval_ref` into some other ml file a= nd >> >>>>>> 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 > >