From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 3FCEA7EFCD; Tue, 14 Oct 2014 16:55:23 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of whitequark@whitequark.org) identity=pra; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of whitequark@whitequark.org designates 176.58.103.125 as permitted sender) identity=mailfrom; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; 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.whitequark.org) identity=helo; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="postmaster@mail.whitequark.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0YABE5PVSwOmd9/2dsb2JhbABbg2FYAYI1tkAGgUGRfYdLAoEqAX2EAgEBAQMBOAI/EAQHGC4sKwYTCBOIGwwJxlUBAQEBAQUBAQEBHoYghA2FCYEPB4RLBYtYimOIeopyiTWCNIFIOC8BAYJIAQEB X-IPAS-Result: An0YABE5PVSwOmd9/2dsb2JhbABbg2FYAYI1tkAGgUGRfYdLAoEqAX2EAgEBAQMBOAI/EAQHGC4sKwYTCBOIGwwJxlUBAQEBAQUBAQEBHoYghA2FCYEPB4RLBYtYimOIeopyiTWCNIFIOC8BAYJIAQEB X-IronPort-AV: E=Sophos;i="5.04,717,1406584800"; d="scan'208";a="83224935" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail3-smtp-sop.national.inria.fr with ESMTP; 14 Oct 2014 16:55:15 +0200 Received: by mail.whitequark.org (Postfix, from userid 33) id F359110BDEB; Tue, 14 Oct 2014 14:55:12 +0000 (UTC) To: Jun Furuse X-PHP-Originating-Script: 1000:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 14 Oct 2014 18:55:12 +0400 From: Peter Zotov Cc: Alain Frisch , caml-list , caml-list-request@inria.fr In-Reply-To: References: <8d73ce9dd0bb6d400565617d992736b5@whitequark.org> <543BE7A5.5090208@frisch.fr> Message-ID: <78874d6b72b958db5e74b9b21c18e8d2@whitequark.org> X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/1.0.1 Subject: Re: [Caml-list] [ANN] ppx_overload : ppx for user definable SML style overloading On 2014-10-14 17:08, Jun Furuse wrote: > I do not think the ppx cookies can help ppx_overload in toplevel... It > requires typing environments which can be big. Maybe possible but > sounds odd. > > In toplevel, it should be natural that ppx filters would keep living > along with the main toplevel process, rather than respawning it for > each toplevel phrase. But I understand the current design does not > permit such filter behavior. If this is the case, then Alain's solution would help. Basically, you could store only the modules with overloaded values in the cookies, as parsetree fragments, which would not be very big. > > Jun > > On Mon, Oct 13, 2014 at 10:54 PM, Alain Frisch wrote: >> On 10/13/2014 03:56 PM, Peter Zotov wrote: >>> >>> On 2014-10-13 17:49, Jun Furuse wrote: >>>> >>>> Hi, >>>> >>>> I have OPAM-released ppx_overload, a ppx for user definable SML >>>> style >>>> overloading. >>> >>> >>> Hi, >>> >>> Great hack! I wanted to do something similar, but yours is much more >>> elegant than what I had in mind. >>> >>> One note though: >>> >>>> Unfortunately this ppx trick does not work for the toplevel. It is >>>> since OCaml toplevel >>>> re-execute the ppx filter each time it gets a toplevel phrase. This >>>> makes the ppx filter >>>> hard to keep its state, in this case, the typing environment. >>> >>> >>> In 4.02.1 the toplevel allows the ppx rewriter to save some state. >>> See >>> >>> http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/trunk/parsing/ast_mapper.mli?view=markup#l192. >> >> >> >> And sedlex ( https://github.com/alainfrisch/sedlex ) illustrates one >> possible approach for storing the state. Instead of marshaling in any >> form >> some kind of internal state, it simply stores fragments of parsetree >> (here, >> structure items) that impacted its internal state and simply replay >> them on >> later phrases. (This is not very efficient, but for quick experiments >> in >> the toplevel, this is fine.) I don't know if this technique would >> apply to >> ppx_overload. >> >> -- Alain >> >> >> -- Peter Zotov