220 18085 <555D1CBC.1030805@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Functional Parsing library Re: Parsing Numbers Date: Thu, 21 May 2015 01:46:04 +0200 Lines: 114 Approved: news@gmane.org Message-ID: <555D1CBC.1030805@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1432165580 1643 80.91.229.3 (20 May 2015 23:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 May 2015 23:46:20 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDH67CONY4PBBPVZ6SVAKGQECHI3YYA@isocpp.org Thu May 21 01:46:08 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f198.google.com ([209.85.217.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YvDgd-00045H-Ta for gclcip-std-proposals@m.gmane.org; Thu, 21 May 2015 01:46:07 +0200 Original-Received: by lbbqq2 with SMTP id qq2sf1993005lbb.0 for ; Wed, 20 May 2015 16:46:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=AtyC0bhTL9upuwRVgyqSlMXmyRYMkgh6hHzBXmj1DMU=; b=MhztjP0Z0szrEOvxtu0LGstOrfewE+ql0paSNv0EGt5UzF7S8hYJ49nXumKDO/HINy cAqlmtpKsSAeyO1OqA1v3xyxygx2GkOBD2LOcKuwxUlVVZWNW6/4L1QsDAkm6ft7P98b HH+zagK1vINxN2W0mezIxMlYLHBwEQNUF44qgMwCNUl++NBm0QaBOtQMocr0JDI7p/YK Yo8twT37Ft+WdZMmmoXXxQ+gEzHUfVELf1K5zP6AtVgyuMGgTKn1EQ3zDzK40hJaMBxx xitQTXxf9GQcVmQPJBdzTXgy+guSUxuvtFyXtCNh95nICeajR7Y+9ekQ6U/JjLz86qca Xnpg== X-Gm-Message-State: ALoCoQmOqnVRLq2P8eETRTTfm2dCCO7Xe/Mm/ryXdHmpKKvv01Rx8lXjFCthMBAxq57SYvFEuG8O X-Received: by 10.112.26.5 with SMTP id h5mr28701229lbg.4.1432165567221; Wed, 20 May 2015 16:46:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.105.132 with SMTP id gm4ls519047wib.31.gmail; Wed, 20 May 2015 16:46:06 -0700 (PDT) X-Received: by 10.194.81.234 with SMTP id d10mr61967187wjy.84.1432165566124; Wed, 20 May 2015 16:46:06 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr. [80.12.242.131]) by mx.google.com with ESMTPS id p9si10525140wjr.193.2015.05.20.16.46.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 May 2015 16:46:06 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.131 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.131; Original-Received: from new-host.home ([92.139.141.131]) by mwinf5d17 with ME id WPm41q00F2qJ0z803Pm5xG; Thu, 21 May 2015 01:46:05 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 21 May 2015 01:46:05 +0200 X-ME-IP: 92.139.141.131 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.131 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.fr Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:18085 Archived-At: I agree with Jeffrey, but I don't want to stop the discussion about a=20 possible functional parser. I don't know if there is enough people interested in a functional=20 proposal. It can be based on work ongoing as FTL, Fit and others as Hana=20 (even if Hana is also a meta-programming library). I suggest to let the=20 Parsing Numbers thread for a proposal more in line with the current=20 standard library and continue here what could be a parser library using=20 the functional paradigm. I propose to evaluate the minimum necessary to=20 make this parser library implementable. Some themes * High Order Functions * Monads and other Categories Maybe the 'pure' functional programming paradigm is not the C++ way, but=20 I find it very elegant, readable and productive. Of course, it represents a clear shift when we compare it with=20 imperative or object oriented programming paradigms. I hope that people understand that it is not the intention of any of us=20 to delay any proposal. Some of us just think that there is an=20 alternative way, but this way need some basic tools that we don't have yet. Sorry for all the functional noise ;-) Vicente Le 21/05/15 00:59, 'Jeffrey Yasskin' via ISO C++ Standard - Future=20 Proposals a =C3=A9crit : > There's a significant risk here that if the proposal is too > complicated, nothing will get accepted. > > Jens' suggestion has an advantage that it's clearly sufficient and in > line with the rest of the library, even if the interface might not be > as convenient as some other options. Even the interface, though, isn't > too bad when you look at the code using it. > > On Wed, May 20, 2015 at 1:20 PM, Miro Knejp wrote: >> The Functional Template Library ( https://github.com/beark/ftl ) has an >> example of monadic parser generators inspired by Haskell. >> https://github.com/beark/ftl/blob/master/docs/Parsec-I.md >> >> Now that library also has overloads of operator>>=3D and others, which i= s not >> part of "turn a string into an int" problem, but with all parsing functi= ons >> returning parser monads the composition is much easier to do. >> >> It starts of by introducing the monad itself: >> >> template >> using parser =3D ftl::eitherT= >; >> >> >> and a function to execute the actual parser >> >> template >> ftl::either run(parser p, std::istream& is); >> >> >> Each parsing function then returns a parser object. >> >> parser parseNatural(); >> >> >> This obviously serves more than a simple "turn a string into an int" but= is >> a prime example of composability that really shines with the combining >> operators like >> or << etc. It makes things like this easy >> >> parser> parseLispList() { >> using namesapce ftl; >> return parseChar('(') >> >> parseList() >> << parseChar(')'); >> } >> >> >> I thought I'd throw this in just as an example. We had these discussions >> earlier without any consensus and the only new viewpoint brought in this >> time is the functional approach mentioned by Vicente J. Whether this is >> something the standard library can/should follow, or provides the >> performance people need, or it can solve all the use cases people can co= me >> up with and make everyone happy I don't know. >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Group= s >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to std-proposals+unsubscribe@isocpp.org. >> To post to this group, send email to std-proposals@isocpp.org. >> Visit this group at >> http://groups.google.com/a/isocpp.org/group/std-proposals/. --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. .