From: "Ömer Sinan Ağacan" <omeragacan@gmail.com>
To: OCaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Problems with printing MetaOCaml generated code
Date: Thu, 30 Apr 2015 16:57:18 -0400 [thread overview]
Message-ID: <CAMQQO3ngKhpyTm74ouh32QfLREp2T2B7r8SyjCnziLor7dgT=A@mail.gmail.com> (raw)
In-Reply-To: <CAMQQO3ka1ZLJ547rGcA4mzrJC6zqateDmP-JaRmM5HGWi-evEg@mail.gmail.com>
Let's talk on an example:
-- contents of TestData.ml
type foo = Foo of int
-- contents of main
open TestData
let global_ref : int ref = ref 0
let gen_inc =
.< let _ = global_ref := !global_ref + 1 in () >.
let gen_read =
.< !global_ref >.
let gen_write i =
.< match i with
| Foo i -> global_ref := i
>.
let gen_cls_wrt cls =
.< global_ref := cls () >.
let f_toplevel () = Random.int 10
let _ =
print_string "\n----------------------------\n";
let _ = Print_code.print_code Format.std_formatter gen_inc in
print_string "\n----------------------------\n";
let _ = Print_code.print_closed_code Format.std_formatter
(Runcode.close_code gen_inc) in
print_string "\n----------------------------\n";
let _ = Print_code.print_closed_code Format.std_formatter
(Runcode.close_code (gen_write (Foo 10))) in
print_string "\n----------------------------\n";
let _ = Print_code.print_closed_code Format.std_formatter
(Runcode.close_code gen_read) in
print_string "\n----------------------------\n";
let f () = Random.int 10 in
let _ = Print_code.print_closed_code Format.std_formatter
(Runcode.close_code (gen_cls_wrt f)) in
print_string "\n----------------------------\n";
let _ = Print_code.print_closed_code Format.std_formatter
(Runcode.close_code (gen_cls_wrt f_toplevel)) in
print_string "\n----------------------------\n";
()
MetaOCaml does some very interesting/weird stuff here:
* In printed code it doesn't always show the CSP values, it just says "CSP
global_ref" for example, but it does that only sometimes. As an example, it
does that for global_ref, but doesn't do that for f_toplevel. I don't
understand how are these two any different. I can refer to top level names
but only sometimes...
It shows the CSP values in some simple cases, for example if the value is an
int than it just shows the literal. (not shown in this example)
* I don't know if this is MetaOCaml related, but output of this program is
interleaved. Instead of printing a line than code it prints two lines and
then two code etc. How is this possible??
For the reference, the output I'm getting:
➜ metaocaml_test git:(master) ✗ ./a.out
File "metaocaml_test.ml", line 17, characters 19-22:
Warning 22: The CSP value is a closure or too deep to serialize
File "metaocaml_test.ml", line 17, characters 19-22:
Warning 22: The CSP value is a closure or too deep to serialize
----------------------------
----------------------------
.<let _ = (* CSP global_ref *) := ((! (* CSP global_ref *)) + 1) in ()>. .<
let _ = (* CSP global_ref *) := ((! (* CSP global_ref *)) + 1) in ()>.
----------------------------
.<
match (* CSP i *) with | TestData.Foo i_1 -> (* CSP global_ref *) := i_1>.
----------------------------
.<
! (* CSP global_ref *)>.
----------------------------
.<
----------------------------
(* CSP global_ref *) := ((* CSP cls *) ())>. .<
(* CSP global_ref *) := ((* CSP cls *) ())>.
----------------------------
2015-04-30 16:25 GMT-04:00 Ömer Sinan Ağacan <omeragacan@gmail.com>:
> Thanks for the answer.
>
> My main problem is not that some generated code are not printable -- rather,
> it's not clear at all when a code is not printable. Now I have to play around
> with code until suddenly it's printable...
>
> Certainly not all code is printable even in theory, for example, what happens
> if my generated code captures a file handle from code generator? Or a heap
> object that's completely opaque to runtime system.(no type information etc.) In
> those cases it may be possible to directly run the code but it's not possible
> to print it.
>
> But IMHO MetaOCaml should have done a better job at reporting those. Or at
> least at least documenting when it's not possible.
>
> I guess I have to play around and see if some of my random changes make it
> printable.
>
> ---
> Ömer Sinan Ağacan
> http://osa1.net
>
>
> 2015-04-30 15:52 GMT-04:00 Jacques Carette <carette@mcmaster.ca>:
>> You will have some difficulties printing complex closures, especially when
>> they refer to values built in the generator (CSPs) which are not simple
>> values (strings, integers, etc).
>>
>> Sometimes, very simple changes to the generator can allow closures and CSPs
>> to be printable or not -- without very specific examples, I can't help (it's
>> been a few years since I dug into this deeply).
>>
>> I have been able to print rather complex, large codes with metaocaml. But
>> one has to structure the generator rather carefully to ensure this
>> possibility.
>>
>> Jacques
>>
>>
>> On 2015-04-30 14:36 , Ömer Sinan Ağacan wrote:
>>>
>>> Hi all,
>>>
>>> I'm working on a MetaOCaml program and I want to save generated programs
>>> to
>>> files instead of directly running them within the same program using
>>> `Runcode.(.!)` or `Runcode.run`. The problem is MetaOCaml never prints
>>> generated code, it's always failing with `Warning 22: The CSP value is a
>>> closure or too deep to serialize`.
>>>
>>> I can't see anything related in it's web page:
>>> http://okmij.org/ftp/ML/MetaOCaml.html. What I understand from that page
>>> is
>>> once I have a closed code, I should be able to print it no matter what.
>>> However in my experience even the simplest realistic MetaOCaml program
>>> fails to
>>> generate the code because of this error I mentioned above.
>>>
>>> (One thing to note here is that my program generates the code on a couple
>>> of
>>> inputs, but fails in most of them with this error message.)
>>>
>>> In "Many ways to run the code" section it's said that "Since closed code
>>> is
>>> essentially OCaml AST, after closing the generated code, the user may
>>> examine
>>> and `run' it in many ways. One way of running the code is printing it."
>>> and
>>> then it lists some API functions for printing. In my experience none of
>>> them
>>> really work, I have closed code which I successfully closed using
>>> `Runcode.close_code`, but `print_closed_code` is still failing with the
>>> error,
>>> and `print_code_as_ast` is printing something that definitely doesn't look
>>> like
>>> an AST for any imaginable programming language.(okay... I might have
>>> exaggerated a bit, but it's definitely not OCaml AST and it contains some
>>> references to generator program source, like "Generator.ml[248]" for
>>> example)
>>>
>>> One relevant thing I could find in the documentation is this: "If the code
>>> includes CSP only as literals or external references (and any code can be
>>> arranged that way), the code can be stored into a file and then passed to
>>> ocamlopt." If we remove this sentence from the documentation, I don't
>>> think it
>>> mentions about any possible failures in code printing.
>>>
>>> So now that I've expressed my frustration about this, I guess my main
>>> question
>>> is: In what cases does MetaOCaml prints generated code? In what cases it
>>> doesn't? Note that it fails to generate code even after calling
>>> `print_closed_code (close_code ...)`, so being closed or not doesn't seem
>>> very
>>> relevent here. Is this a bug in MetaOCaml? Are there any workarounds? Any
>>> ideas
>>> what am I doing wrong?
>>>
>>> Thanks in advance for any answers,
>>>
>>> Ömer
>>>
>>
next prev parent reply other threads:[~2015-04-30 20:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 18:36 Ömer Sinan Ağacan
2015-04-30 19:52 ` Jacques Carette
2015-04-30 20:25 ` Ömer Sinan Ağacan
2015-04-30 20:57 ` Ömer Sinan Ağacan [this message]
2015-04-30 21:35 ` Jeremy Yallop
2015-05-01 11:21 ` oleg
2015-05-01 14:34 ` Ömer Sinan Ağacan
2015-05-01 16:16 ` Leo White
2015-05-01 16:41 ` Ömer Sinan Ağacan
2015-05-01 16:45 ` Leo White
2015-05-01 16:53 ` Ömer Sinan Ağacan
2015-05-02 18:45 ` Ömer Sinan Ağacan
2015-05-02 20:49 ` Jacques Carette
2015-05-03 1:56 ` Ömer Sinan Ağacan
2015-05-03 2:28 ` Jacques Carette
2015-05-03 3:19 ` Ömer Sinan Ağacan
2015-05-03 8:40 ` Gabriel Scherer
2015-05-03 14:28 ` Ömer Sinan Ağacan
2015-05-03 15:24 ` Leo White
2015-05-03 15:50 ` Ömer Sinan Ağacan
2015-05-06 9:50 ` oleg
2015-05-06 15:58 ` Jeremy Yallop
2015-05-06 16:45 ` Yotam Barnoy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMQQO3ngKhpyTm74ouh32QfLREp2T2B7r8SyjCnziLor7dgT=A@mail.gmail.com' \
--to=omeragacan@gmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox