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 C92177EEB4 for ; Sun, 3 Feb 2013 15:39:08 +0100 (CET) Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of simon.cruanes.2007@m4x.org does not assert whether or not 129.104.30.34 is permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=qwa8=L3=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="simon.cruanes.2007@m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of SRS0=qwa8=L3=m4x.org=simon.cruanes.2007@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=qwa8=L3=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="SRS0=qwa8=L3=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=qwa8=L3=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoEACZ1DlGBaB4if2dsb2JhbABEhkimA4lHAYkgFg4BAQsLCggUJ4IfAQEBBAECIEkCBhEECxEEAQEBDRoDAgIoHQEJCAYBEhIJh2QDDwQIrSKHZgOJYI0PgzCBEwOTbYIygR2SMQ X-IPAS-Result: AgoEACZ1DlGBaB4if2dsb2JhbABEhkimA4lHAYkgFg4BAQsLCggUJ4IfAQEBBAECIEkCBhEECxEEAQEBDRoDAgIoHQEJCAYBEhIJh2QDDwQIrSKHZgOJYI0PgzCBEwOTbYIygR2SMQ X-IronPort-AV: E=Sophos;i="4.84,593,1355094000"; d="scan'208,217";a="906670" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 03 Feb 2013 15:35:15 +0100 Received: from android-11593d1dd160940 (143.16.80.79.rev.sfr.net [79.80.16.143]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 2904A140C56C0; Sun, 3 Feb 2013 15:39:03 +0100 (CET) User-Agent: K-9 Mail for Android In-Reply-To: <017801ce0216$f2b2c020$d8184060$@ffconsultancy.com> References: <510145A5.6030807@frisch.fr> <90C5BC201F264C4C902B4E7897660042@erratique.ch> <1359044659.30715.4@samsung> <51066BCA.1020201@frisch.fr> <017801ce0216$f2b2c020$d8184060$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----L2EFSAHW4GZVYIVLA7OZ3HSOJ663HK" From: Simon Cruanes Date: Sun, 03 Feb 2013 15:38:59 +0100 To: Jon Harrop ,'caml-list' Message-ID: X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Sun Feb 3 15:39:04 2013 +0100 (CET)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.000000, queueID=603BB140C56C2 X-Org-Mail: simon.cruanes.2007@polytechnique.org Subject: RE: AW: [Caml-list] Working Group: the future of syntax extensions in OCaml, after camlp4 ------L2EFSAHW4GZVYIVLA7OZ3HSOJ663HK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I like the idea of inline lexer/parsers. A problem I have with ocamllex/ocamlyacc is the fact that circular dependencies prevent from using/exporting a parser for some type in the same module where this type is defined. Inline parsers would allow to keep the type and its parser(s) defined together. First-class parsers, even better, would be great for composition. Cheers, -- Simon Jon Harrop a écrit : > >I worked on a commercial project written in OCaml in Q4 2012 that used >stream parsing. However, my project was to translate the whole thing >into >F#... > >I never used stream parsing in any commercial code I wrote myself. I >did use >camlp4 quite a bit though and, I must say, the only problem I had was >that >it was never finished (the docs end in "..."!). Moreover, my main >practical >application of camlp4 was in using it to write parsers. Parsers written >using Camlp4 are nicer than with any other tool I have ever used. Would >be a >shame if OCaml lost this or, if it did, gained the ability to write >lex/yacc >in-line without having to battle with multi-stage compilation and a >wide >selection of incomplete/broken build tools. > >Cheers, >Jon. > >> -----Original Message----- >> From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] >On >Behalf >> Of Alain Frisch >> Sent: 28 January 2013 12:15 >> To: Gerd Stolpmann >> Cc: Daniel Bünzli; caml-list; wg-camlp4@lists.ocaml.org; Leo P White; >Anil >> Madhavapeddy >> Subject: Re: AW: [Caml-list] Working Group: the future of syntax >extensions in >> OCaml, after camlp4 >> >> On 01/24/2013 05:24 PM, Gerd Stolpmann wrote: >> > It's used in the tool, but only for stream parsing. I could also >> > distribute the already-preprocessed file (and maybe I'll do so in >the >> > next release). >> > >> > Stream parsing is certainly one of the topics to discuss. >> >> I've no idea how widely stream parsing is used. Has anyone some >intuition >> about this? >> >> Stream parsers probably fall in the same category as bitstring or >sedlex >(custom >> notions of pattern matching). It seems that stream parsers (which >I'm not >> familiar with) require to be able to write expressions within >"left-hand >sides", >> which might require special support. Or maybe the whole left-hand >sides >should >> just be quotations. >> >> Anyway, for a basic infrastructure tool such as ocamlfind, I'd >probably >advocate >> for a "manual" solution which works out of the box with a basic OCaml >> installation (ocamlyacc or manual top-down parser). Gerd: does that >sound >> reasonable to you? >> >> >> Alain >> >> >> -- >> 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 > > >-- >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 ------L2EFSAHW4GZVYIVLA7OZ3HSOJ663HK Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I like the idea of inline lexer/parsers. A problem I have with ocamllex/ocamlyacc is the fact that circular dependencies prevent from using/exporting a parser for some type in the same module where this type is defined. Inline parsers would allow to keep the type and its parser(s) defined together. First-class parsers, even better, would be great for composition.

Cheers,
--
Simon


Jon Harrop <jon@ffconsultancy.com> a écrit :

I worked on a commercial project written in OCaml in Q4 2012 that used
stream parsing. However, my project was to translate the whole thing into
F#...

I never used stream parsing in any commercial code I wrote myself. I did use
camlp4 quite a bit though and, I must say, the only problem I had was that
it was never finished (the docs end in "..."!). Moreover, my main practical
application of camlp4 was in using it to write parsers. Parsers written
using Camlp4 are nicer than with any other tool I have ever used. Would be a
shame if OCaml lost this or, if it did, gained the ability to write lex/yacc
in-line without having to battle with multi-stage compilation and a wide
selection of incomplete/broken build tools.

Cheers,
Jon.

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On
Behalf
Of Alain Frisch
Sent: 28 January 2013 12:15
To: Gerd Stolpmann
Cc: Daniel Bünzli; caml-list; wg-camlp4@lists.ocaml.org; Leo P White; Anil
Madhavapeddy
Subject: Re: AW: [Caml-list] Working Group: the future of syntax
extensions in
OCaml, after camlp4

On 01/24/2013 05:24 PM, Gerd Stolpmann wrote:
It's used in the tool, but only for stream parsing. I could also
distribute the
already-preprocessed file (and maybe I'll do so in the
next release).

Stream parsing is certainly one of the topics to discuss.

I've no idea how widely stream parsing is used.  Has anyone some intuition
about this?

Stream parsers probably fall in the same category as bitstring or sedlex
(custom
notions of pattern matching).  It seems that stream parsers (which I'm not
familiar with) require to be able to write expressions within "left-hand
sides",
which might require special support.  Or maybe the whole left-hand sides
should
just be quotations.

Anyway, for a basic infrastructure tool such as ocamlfind, I'd probably
advocate
for a "manual" solution which works out of the box with a basic OCaml
installation (ocamlyacc or manual top-down parser).  Gerd: does that sound
reasonable to you?


Alain


--
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

------L2EFSAHW4GZVYIVLA7OZ3HSOJ663HK--