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 <miro.knejp@gmail.com> 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<typename T>
>>      using parser =3D ftl::eitherT<error,ftl::function<T(std::istream&)>=
>;
>>
>>
>> and a function to execute the actual parser
>>
>> template<typename T>
>>      ftl::either<error,T> run(parser<T> p, std::istream& is);
>>
>>
>> Each parsing function then returns a parser object.
>>
>> parser<int> 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<std::vector<int>> 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/.

.

Thanks for starting a new thread. I do think a separate paper about a
combinator parsing library would be a good thing for the committee to
see. One thing that I think would be especially convincing would be
examples of well-known projects using these libraries or techniques
where the authors don't look like functional programming enthusiasts.
e.g. is someone parsing some financial format with a C++ combinator
library?

On Wed, May 20, 2015 at 4:46 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> I agree with Jeffrey, but I don't want to stop the discussion about a
> possible functional parser.
>
> I don't know if there is enough people interested in a functional proposa=
l.
> It can be based on work ongoing as FTL, Fit and others as Hana (even if H=
ana
> is also a meta-programming library). I suggest to let the Parsing Numbers
> thread for a proposal more in line with the current standard library and
> continue here what could be a parser library using the functional paradig=
m.
> I propose to evaluate the minimum necessary to 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 =
I
> find it very elegant, readable and productive.
> Of course, it represents a clear shift when we compare it with imperative=
 or
> object oriented programming paradigms.
>
> I hope that people understand that it is not the intention of any of us t=
o
> delay any proposal. Some of us just think that there is an alternative wa=
y,
> 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 Propos=
als
> 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 <miro.knejp@gmail.com> 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 =
is
>>> not
>>> part of "turn a string into an int" problem, but with all parsing
>>> functions
>>> returning parser monads the composition is much easier to do.
>>>
>>> It starts of by introducing the monad itself:
>>>
>>> template<typename T>
>>>      using parser =3D ftl::eitherT<error,ftl::function<T(std::istream&)=
>>;
>>>
>>>
>>> and a function to execute the actual parser
>>>
>>> template<typename T>
>>>      ftl::either<error,T> run(parser<T> p, std::istream& is);
>>>
>>>
>>> Each parsing function then returns a parser object.
>>>
>>> parser<int> parseNatural();
>>>
>>>
>>> This obviously serves more than a simple "turn a string into an int" bu=
t
>>> is
>>> a prime example of composability that really shines with the combining
>>> operators like >> or << etc. It makes things like this easy
>>>
>>> parser<std::vector<int>> parseLispList() {
>>>      using namesapce ftl;
>>>      return parseChar('(')
>>>          >> parseList()
>>>          << parseChar(')');
>>> }
>>>
>>>
>>> I thought I'd throw this in just as an example. We had these discussion=
s
>>> earlier without any consensus and the only new viewpoint brought in thi=
s
>>> 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
>>> come
>>> up with and make everyone happy I don't know.
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Grou=
ps
>>> "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send =
an
>>> 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/.
>
>
> --
>
> --- 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
> 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/.

.