From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTP id 877B05D4 for ; Sun, 29 Jul 2018 00:26:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.51,416,1526335200"; d="scan'208,217";a="340608457" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 29 Jul 2018 02:26:54 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 2C5C7824B2; Sun, 29 Jul 2018 02:26:54 +0200 (CEST) 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 A948981792 for ; Sun, 29 Jul 2018 02:26:44 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=martindemello@gmail.com; spf=Pass smtp.mailfrom=martindemello@gmail.com; spf=None smtp.helo=postmaster@mail-vk0-f52.google.com IronPort-PHdr: =?us-ascii?q?9a23=3AHkQUuRU+V9u7ph2e2STnLQpMKb/V8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYYxyAt8tkgFKBZ4jH8fUM07OQ7/i+HzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjWwba9zIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZAIy8?= =?us-ascii?q?YYsBAeQCM+hFsYfyu0ADogGiCQS2Hu7j1iNEi33w0KYn0+ohCwbG3Ak4EtwJqn?= =?us-ascii?q?vUtsn1NKYUUeuowqfH0zLNYO1S2Tf574jDbxcsofSWUrJqbcrRyE8vGB7bgVWV?= =?us-ascii?q?t4PlOzeV1uMWvmiU6upvT+Ovi2o9pw5tpTivw94hh4/UjYwW0lDJ7Tt1zJoxKN?= =?us-ascii?q?GiS0N2YcSoHIVNuyyULYd7Qt0uTmd1sygg0LIGo4S0fC0SxZQn2RHfb/uHfpCN?= =?us-ascii?q?4h35VeaRJS50hGxmeL6jnhqy/0itxvPmWsm711ZKqSVFkt3SuXwXyxPT7c2HRu?= =?us-ascii?q?N8/kenxzmPyxje5v9YLU0wj6bWKJ4szqQumpYOv0nPBC/7lFvugK+TbEok++yo?= =?us-ascii?q?6+r9YrXho5+RL4p0hRvkMqQym8y/B/k3PRYLX2eF/eS80Lrj8Fb2QLVPlPI2k6?= =?us-ascii?q?3ZvIrGKsQco661GxVV3Zo76xajEzem18wVkmUdI1JAfBKLlozpO1DVIPDkFvq/?= =?us-ascii?q?mFStkDJzx//cJLHhA5PNLmLCkLj7Z7p95VRcm0IPyoV86pRSB60BaNv/U0q5kd?= =?us-ascii?q?3cChIje1i3zuDhBcl9348XXGeOBquUKovdtFaJ4qQkJOzaN6EPvzOoDvE/+//o?= =?us-ascii?q?xVM0vFIZea7hiZ4ecmy5GPhrJkidZX3EjdIIEGNMtQ07Gr+5wGaeWCJeMi7hF5?= =?us-ascii?q?k34Ss2Xcf/Vd+aF9KdxYeZ1SL+JaV4I2VPC1SCC3DtLtzWVPIFaSbUKchkwGVd?= =?us-ascii?q?CeqRDrQ53BTrjzfUjqJ9J7ONqCIdvJPnktNy4r+LzExgxXlPF82Yllq1YSR0k2?= =?us-ascii?q?cPHWJk2al+pQljyQ/G3/UixfNfEtNX6rVCVQJobZM=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AQB8CF1bhzTVVdFcHAEBAQQBAQoBA?= =?us-ascii?q?YMgghAVE4N+gR2CUJBUgg2IT4dshxALhGwCgnsZBwEEMxUBAgEBAgEBAQEBEwE?= =?us-ascii?q?BAQgNCQgbDiMMgjUkAYJcAQEBAQIBIx0BGx0BAwELBgMCCw0qAgIhAQERAQUBH?= =?us-ascii?q?AYTgyCBZwEDDQiOf5ACPIsJgREFAReCdQWDTQoZJg1XgksCBhKIcBeBQT+DJn6?= =?us-ascii?q?CVoUpglUCiB+FOYwNKwmMK4MMjgmLI4cFDyGBNoF0cFAxgjiCGRqDTopxIDCPf?= =?us-ascii?q?AEB?= X-IPAS-Result: =?us-ascii?q?A0C6AQB8CF1bhzTVVdFcHAEBAQQBAQoBAYMgghAVE4N+gR2?= =?us-ascii?q?CUJBUgg2IT4dshxALhGwCgnsZBwEEMxUBAgEBAgEBAQEBEwEBAQgNCQgbDiMMg?= =?us-ascii?q?jUkAYJcAQEBAQIBIx0BGx0BAwELBgMCCw0qAgIhAQERAQUBHAYTgyCBZwEDDQi?= =?us-ascii?q?Of5ACPIsJgREFAReCdQWDTQoZJg1XgksCBhKIcBeBQT+DJn6CVoUpglUCiB+FO?= =?us-ascii?q?YwNKwmMK4MMjgmLI4cFDyGBNoF0cFAxgjiCGRqDTopxIDCPfAEB?= X-IronPort-AV: E=Sophos;i="5.51,416,1526335200"; d="scan'208,217";a="274331807" Received: from mail-vk0-f52.google.com ([209.85.213.52]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 29 Jul 2018 02:26:42 +0200 Received: by mail-vk0-f52.google.com with SMTP id k82-v6so4163375vkd.5 for ; Sat, 28 Jul 2018 17:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4wt8iAuMBTGUrF2MfAB0CuS1DW9w9YE0xzG1y7M9bGc=; b=iHqBugOdMAhgsPE81eyJap63+n3B7atQYHWb0BUcKSbCYgjaioRiTSrs2MV8QWZXQB h/I0NMHmydj9Q1hxAbDupTkEiGko97p0EpgS9tgJiyMdJgTz1eNFymN/iegErqsWcrek Jw0sKEJHN6438Xzhfe0tkbaKvCLBLhBW3uKm3AmbDSfnpACjQogbYG6MJPP4EHOkBVjm si1a9Zu0Gxevz5vtfRuNQwqnRm678lrAjqKQQsnvklspkQvXTln7mz7G1s6m6wQjsXMp zemZoW6Ta0kVQRngNAZRUCuQbHwowdy3j28vpFQaAMJd1j2C8FJ28GfjLIgy8+5t5+Z7 LbUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4wt8iAuMBTGUrF2MfAB0CuS1DW9w9YE0xzG1y7M9bGc=; b=uj0So5wyW9DFmwjjgF0tSSpIRKREpUBtdBUDHGHFjsllekmSx9XBJzVUHgE7vA9aA8 oTT92OezOWV42AH5c5mLTPHtgvd7x6VNYz2nGYi7RoEJPgLKTYrWo94IuRDKbBs3Jpcr kLUv/oGra2ZygVj0Z9Vjnk4/H5hJYlQ+jSDe21rrhJtIRYvUmvvbas3nQEJBQTPp0UKp KFD1/z5LLznyw4h/GNB5S2C5yelfVUhoD6eVKS60cWDjI7Pe8pTvaixvOR0DyCDbrwv5 ysnwXvVv1q0bby6P6XILyTeLchCwuwloFrV3NWUhWx7s4AHmK5jc0uaTkVafBluiPoay VI1g== X-Gm-Message-State: AOUpUlHqyMkRve1Mjf5/iC9jOBzPig40858mDnVS2hzKr1Hc4U/AX6Gi lSq3lU4XbOE+TZeKIw49oHhi9yMD8v+sdTVLXQw= X-Google-Smtp-Source: AAOMgpepJH76GvKHHPodyLomiEJwqenFkqJnuxtnK7PUAZPpphgDJhzbDg8mciNkLleLTM0EofTPy7K73O/r6tGSo8k= X-Received: by 2002:a1f:19c8:: with SMTP id 191-v6mr7425210vkz.162.1532824001251; Sat, 28 Jul 2018 17:26:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:790d:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 17:26:40 -0700 (PDT) In-Reply-To: References: <14267431532800443@iva1-3d0d937e850f.qloud-c.yandex.net> From: Martin DeMello Date: Sat, 28 Jul 2018 18:26:40 -0600 Message-ID: To: Kenneth Adam Miller Cc: vkni@yandex.ru, caml users Content-Type: multipart/alternative; boundary="000000000000190c970572186669" Subject: Re: [Caml-list] cmdliner difficulties Reply-To: Martin DeMello X-Loop: caml-list@inria.fr X-Sequence: 17016 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000190c970572186669 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How about "lexing" them into a list of operation tokens, then using the shunting-yard algorithm to parse them into an expression tree? that would allow arbitrary recursive expressions and still be relatively straightforward to process. martin On Sat, Jul 28, 2018 at 2:16 PM, Kenneth Adam Miller < kennethadammiller@gmail.com> wrote: > I understand other people have written those things before, and that it's > probably not so challenging to someone else, and I'm not saying I can't or > wouldn't write it, but I'm under deadline pressure, and I think it would > not be looked up on well if I had something with anywhere near so many > features or as much work to deliver since if they even exist. Since I have > to demonstrate this, the first question they are going to ask is "you spe= nt > more than X minutes working on this when you could have been working on t= he > minimum viable product!! Unhappy!!" So I'm not disregarding the input I've > got, but I think that I can achieve a less robust working version with the > same set of features in a simpler fashion. > > So, instead I think can get something very near to a full grammar, while > still allowing the fundamental operations I want. Here's what I've got: > > > type setop =3D > | Intersection > | Difference > | Union > [@@deriving sexp] > > let list_setops =3D [ > "Intersection", Intersection; > "Difference", Difference; > "Union", Union; > ] > let setops_doc =3D List.(to_string ~f:fst (list_setops)) > let setops =3D > let doc =3D "." in > Cmdliner.Arg.( > value & opt_all (some (pair ~sep:'=3D' string & pair (enum > (list_setops)) & pair string string)) [] > & info ["setop"] ~docv:setops_doc ~doc > ) > > > Instead of having an recursive variant instance in the type setop place to > allow the grammar to be recursive, I will fold over the setops, and add > each one to a map. For example, I might have: > > --setop Red=3DUnion (Feature1, Feature2) --setop Green=3DIntersection (Re= d, > Feature3) > > So that, as I fold, I will add colors to the feature set. Then, for > whatever nested operations otherwise would have been required, I can just > manually unfold them on the command line. > > I guess I've solved my problem, but I was hoping to get a recursive > parsing capability on the command line that would have supporting a type > declaration more like the following: > > type setop =3D > | Result of setop > | Intersection of string * string > | Difference of string * string > | Union of string * string > > The problem with this is, 1) the constructors are non-uniform so that > there isn't a clean way to specify to the Cmdliner.Arg.value function what > the converter should be 2) The list type of their resulting pairwise > sub-command specifications to the command line (the "enum list_setops" > part) becomes much harder to specify since those also need to be > constructible in the string - type pairs for the list_setops argument to > enum. > > I suppose my thinking about how to deal with this would be to write a > custom conv to convert the command line input, but to do so it would have > to be recursive, and the Cmdliner.Arg.enum would have to support both > non-uniform constructors and an argument conv to be able to do this > correctly. > > Does anybody have a better way to capture what I'm looking to do? > > On Sat, Jul 28, 2018 at 10:54 AM =D0=90=D0=BD=D0=B4=D1=80=D0=B5=D0=B9 =D0= =91=D0=B5=D1=80=D0=B3=D0=BC=D0=B0=D0=BD wrote: > >> Probably a parser combinator with a small language would be a better tool >> for that. Parser generators look too heavy, and comman-line parsers are = too >> light (otherwise they become optparse-applicative, which is too specific= to >> study it =3D> everyone uses cookbook). >> > --=20 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= --000000000000190c970572186669 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How about "lexing" them into a list of operation= tokens, then using the shunting-yard algorithm to parse them into an expre= ssion tree? that would allow arbitrary recursive expressions and still be r= elatively straightforward to process.

martin
=

On Sat, Jul 28, 2= 018 at 2:16 PM, Kenneth Adam Miller <kennethadammiller@gmail.com= > wrote:
I= understand other people have written those things before, and that it'= s probably not so challenging to someone else, and I'm not saying I can= 't or wouldn't write it, but I'm under deadline pressure, and I= think it would not be looked up on well if I had something with anywhere n= ear so many features or as much work to deliver since if they even exist. S= ince I have to demonstrate this, the first question they are going to ask i= s "you spent more than X minutes working on this when you could have b= een working on the minimum viable product!! Unhappy!!" So I'm not = disregarding the input I've got, but I think that I can achieve a less = robust working version with the same set of features in a simpler fashion.<= br>
So, instead I think can get something very near to a full gramm= ar, while still allowing the fundamental operations I want. Here's what= I've got:


type setop =3D
=C2=A0 |= Intersection
=C2=A0 | Difference
=C2=A0 | Union
<= div>[@@deriving sexp]

let list_setops =3D [
<= div>=C2=A0 =C2=A0 "Intersection", Intersection;
=C2=A0 = =C2=A0 "Difference", Difference;
=C2=A0 =C2=A0 "Un= ion", Union;
]
let setops_doc =3D List.(to_string = ~f:fst (list_setops))
let setops =3D
=C2=A0 let do= c =3D "." in
=C2=A0 Cmdliner.Arg.(
=C2=A0 =C2= =A0 value & opt_all (some (pair ~sep:'=3D' string & pair (e= num (list_setops)) & pair string string)) []
=C2=A0 =C2=A0 &a= mp; info ["setop"] ~docv:setops_doc ~doc
=C2=A0 )
=


Instead of having an recursive variant instance in= the type setop place to allow the grammar to be recursive, I will fold ove= r the setops, and add each one to a map. For example, I might have:

= --setop Red=3DUnion (Feature1, Feature2) --setop Green=3DIntersection (Red,= Feature3)

So that, as I fold, I will add colors to the feature set.= Then, for whatever nested operations otherwise would have been required, I= can just manually unfold them on the command line.=C2=A0

I guess I&= #39;ve solved my problem, but I was hoping to get a recursive parsing capab= ility on the command line that would have supporting a type declaration mor= e like the following:

type setop =3D
=C2=A0 | Result = of setop
=C2=A0 | Intersection of string * string
=C2= =A0 | Difference of string * string
=C2=A0 | Union of string * st= ring

The problem with this is, 1) the constructors are non-uniform s= o that there isn't a clean way to specify to the Cmdliner.Arg.value fun= ction what the converter should be 2) The list type of their resulting pair= wise sub-command specifications to the command line (the "enum list_se= tops" part) becomes much harder to specify since those also need to be= constructible in the string - type pairs for the list_setops argument to e= num.=C2=A0

I suppose my thinking about how t= o deal with this would be to write a custom conv to convert the command lin= e input, but to do so it would have to be recursive, and the Cmdliner.Arg.e= num would have to support both non-uniform constructors and an argument con= v to be able to do this correctly.

Does anybody ha= ve a better way to capture what I'm looking to do?=C2=A0

On Sat, Jul 28, 2018 at 10:54 AM =D0=90=D0=BD=D0=B4=D1=80=D0=B5= =D0=B9 =D0=91=D0=B5=D1=80=D0=B3=D0=BC=D0=B0=D0=BD <vkni@yandex.ru> wrote:
Probably a parser combinator with a small languag= e would be a better tool for that. Parser generators look too heavy, and co= mman-line parsers are too light (otherwise they become optparse-applicative= , which is too specific to study it =3D> everyone uses cookbook).

--000000000000190c970572186669--