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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id EEACF7FCCB for ; Sun, 3 May 2015 05:20:23 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of omeragacan@gmail.com) identity=pra; client-ip=74.125.82.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="omeragacan@gmail.com"; x-sender="omeragacan@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of omeragacan@gmail.com designates 74.125.82.46 as permitted sender) identity=mailfrom; client-ip=74.125.82.46; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f46.google.com) identity=helo; client-ip=74.125.82.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="omeragacan@gmail.com"; x-sender="postmaster@mail-wg0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CSAgDmkkVVmy5SfUpcg19cBYMYxCWGDAKBNQc8EAEBAQEBAQERAQEBAQEGCwsJIS6EIAEBAQMBEhEdARsdAQMBCwYFCw0CAiYCAiEBAREBBQEcBhMbB4d0AQMJCKYBPjGLOYFrgnaIGwoZJw1WhEgBAQEBAQUBAQEBARcBBQ6BE4oYgk2CBTMHgmiBRQWWHoRsgVWBYY1dhRYSI4EMCYIIgisiMYJFAQEB X-IPAS-Result: A0CSAgDmkkVVmy5SfUpcg19cBYMYxCWGDAKBNQc8EAEBAQEBAQERAQEBAQEGCwsJIS6EIAEBAQMBEhEdARsdAQMBCwYFCw0CAiYCAiEBAREBBQEcBhMbB4d0AQMJCKYBPjGLOYFrgnaIGwoZJw1WhEgBAQEBAQUBAQEBARcBBQ6BE4oYgk2CBTMHgmiBRQWWHoRsgVWBYY1dhRYSI4EMCYIIgisiMYJFAQEB X-IronPort-AV: E=Sophos;i="5.13,358,1427752800"; d="scan'208";a="114316891" Received: from mail-wg0-f46.google.com ([74.125.82.46]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 May 2015 05:20:23 +0200 Received: by wgyo15 with SMTP id o15so121206236wgy.2 for ; Sat, 02 May 2015 20:20:22 -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=LWpeENsEBw/WLQ5sY84uXRxjKQRrEOPtEiMmDcVdqYw=; b=yhaPj94XMAXqWYdOQDxzuSy6tPCL92AGdu6Ocw+F7ze9Z6+43TC6+qZ1X+d2V+heKN 8F8fBRD5wXNsUwSZohvWWH4lpFla3wuDw7YCcrdEbp6egOlqPmwAbeIjgq65ydnUiuQ0 L4/daCHSuIpwZ6hmJ1tV+rZyRWzcy/acmReUeXFolgKJh66X+pBDA51YqcdIn69p1XCv wiR8P5TPGChjk7S2AdPQWTqOWth+H7/w2PtFLCcpAp/2Bgb9GM2ZVK4/ExHFN9t3r6lp Y4B1BQmBnysfPrLSmvx3foyyIgrxRZReQdrZmfsk5+aYfALKOMvPa1NobdC3ytCstQTB mXMg== X-Received: by 10.194.121.163 with SMTP id ll3mr21295789wjb.142.1430623222519; Sat, 02 May 2015 20:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.187.212 with HTTP; Sat, 2 May 2015 20:19:42 -0700 (PDT) In-Reply-To: <554587C0.1070500@mcmaster.ca> 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: Sat, 2 May 2015 23:19:42 -0400 Message-ID: To: Jacques Carette Cc: 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 > 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 differe= nt, > 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 exa= mple 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 name= s 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 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 : > 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 differe= nt, > 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 w= ant > 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 th= at >>>> 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 ca= t Syntax.ml >>>> type stx =3D >>>> | A >>>> | B of stx >>>> | C of (stx * stx) >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 ca= t 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 me= taocamlc Syntax.ml >>>> -c >>>> =E2=9E=9C metaocaml_serialization_issue git:(master) =E2=9C=97 me= taocamlc >>>> 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 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. >>> >>> >