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 5F50F7EFCD; Tue, 14 Oct 2014 15:08:39 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jun.furuse@gmail.com) identity=pra; client-ip=209.85.212.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jun.furuse@gmail.com"; x-sender="jun.furuse@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of jun.furuse@gmail.com designates 209.85.212.172 as permitted sender) identity=mailfrom; client-ip=209.85.212.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jun.furuse@gmail.com"; x-sender="jun.furuse@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-wi0-f172.google.com) identity=helo; client-ip=209.85.212.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jun.furuse@gmail.com"; x-sender="postmaster@mail-wi0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BAA8fPVTRVdSslGdsb2JhbABbg2FYBMw1h0sCgQsHFgERAQEBAQcLCwkSMIQDAQEEEi4BGx0BAwwGBQsNLiIBEQEFARwGEyKIBwEDEQ2kXG6NIoMQiQ4KGScNZ4UmAQEBAQEBAQMBAQEBAQEWAQUOkDcHhEsFi1yHJIM7hxCBaopyh0MYKYNlgVAwLwEBgkgBAQE X-IPAS-Result: Al0BAA8fPVTRVdSslGdsb2JhbABbg2FYBMw1h0sCgQsHFgERAQEBAQcLCwkSMIQDAQEEEi4BGx0BAwwGBQsNLiIBEQEFARwGEyKIBwEDEQ2kXG6NIoMQiQ4KGScNZ4UmAQEBAQEBAQMBAQEBAQEWAQUOkDcHhEsFi1yHJIM7hxCBaopyh0MYKYNlgVAwLwEBgkgBAQE X-IronPort-AV: E=Sophos;i="5.04,717,1406584800"; d="scan'208";a="83205680" Received: from mail-wi0-f172.google.com ([209.85.212.172]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 14 Oct 2014 15:08:38 +0200 Received: by mail-wi0-f172.google.com with SMTP id n3so10051125wiv.11 for ; Tue, 14 Oct 2014 06:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qDGJFs/lklfV/oovfCmcIlG5H6NL8snuZnXu9QBZQ/w=; b=DsOXumh9L5R0/HnctkliW11D8by/+Z0Jk1GkTVGu4LnbJSuROFA34Qc2DINpv16PFU T5XS1u9AKbpz/HLbjNvFw6fasiaPonyIiLBREs6DPPa3YvbDOIQ/ihwplLBxgIFa/6NG i+5IDa9wITW3eDtq//m3Zm5Rwz3NtjH+SPP0Dr/pgOFVURBWWTxsCzovL0n+t212GcVE qIv2T48j85jWtbbvMIL+L47yPNSZZ7wRI7Ob6NKFMK/31sS9I1CJ8m15ogbm6HvQ5m2s 9QPDejWvJUEw/3LWvkHo+p0WD0BUhd3xg+4gnzVkr++dndmvcd9XNjvFGyFcMlbOwkye y7zA== MIME-Version: 1.0 X-Received: by 10.180.14.73 with SMTP id n9mr5391980wic.39.1413292117810; Tue, 14 Oct 2014 06:08:37 -0700 (PDT) Received: by 10.194.164.69 with HTTP; Tue, 14 Oct 2014 06:08:37 -0700 (PDT) In-Reply-To: <543BE7A5.5090208@frisch.fr> References: <8d73ce9dd0bb6d400565617d992736b5@whitequark.org> <543BE7A5.5090208@frisch.fr> Date: Tue, 14 Oct 2014 21:08:37 +0800 Message-ID: From: Jun Furuse To: Alain Frisch Cc: Peter Zotov , caml-list , caml-list-request@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] [ANN] ppx_overload : ppx for user definable SML style overloading 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. 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 > > >