Re: [boost] Boost.Convert+Boost.Parameter

Subject: Re: [boost] Boost.Convert+Boost.Parameter
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-03-02 09:36:12

On Saturday, February 28, 2009 12:18 PM
Hartmut Kaiser wrote:
>
> Well, in this case I really prefer:
>
>     using namespace spirit::std_locale;
>     spirit::qi::parse(str, spirit::int_, i);
>
> or, if you need another radix:
>
>     typedef spirit::qi::int_parser<int, 16> hex;
>     spirit::qi::parse(str, hex(), i);
>
> or, if you need exactly 4 hex digits:
>
>     typedef spirit::qi::int_parser<int, 16, 4, 4> hex4;
>     spirit::qi::parse(str, hex4(), i);
>
> etc.
>
> Which is far less convoluted.

I wouldn't want to impose spirit::int_ on a user when int is what they meant.  Provided that can be packaged easily enough, then the idea has merit.

How is user-defined formatting done, though?  Part of the discussion has been to support UDTs with specialized formatting flags.  How and where would those be injected into the process if i = convert<int>(str) were written as parse(str, spirit::int_, i)?

How does your idea handle any-to-any conversions like uuid to long long?  The convert interface offers the ability to convert among any two types.  Will that work with Spirit or does that require both a parser and a generator with some intermediate format?

> <rant>
> I still don't get it. I agree that it might be favorable to
> have a simple
> API for type<-->string conversions.
>
> But as you can clearly see the requirements are piling up and it's
> everything else but simple by now.

I'm not certain anyone has really decided that the large pile of requirements are appropriate.  One of the benefits of lexical_cast is its simplicity.  Emil has argued from the start for nothing more than to_string() and from_string().  Who knows, we may return to that before we're finished.  I know that I'm exploring options and ideas and yours has merit and I like the idea of migrating to full Spirit parsing as needs grow more complex.

> So I ask again:
>
> What's the benefit of coming up with just another full blown
> parser/generator interface in Boost?

Possibly interface simplicity, possibly non-overlapping requirements.  I'm sure most of the alternatives arise from ignorance of what you practically breathe daily.

> What's the benefit of discarding/obsoleting lexical_cast<>()
> as the _really_
> minimal, simple interface?

That's been documented: at least non-throwing calls and support for defaults.  The convert interface also provides for the possibility of any-to-any type conversions.

> Guy's. You're trying to come up with a DSEL (domain specific embedded
> language) for parsing and generating.
> What's it exactly you don't like in Spirits DSEL? Just the
> fact that it
> wasn't _you_ to come up with this particular syntax? Have you
> even looked?

I think you're overly sensitive here.  I suspect Spirit seems overwhelming to those unfamiliar with it and seems targeted for different purposes.  Those not accustomed to parsing, much less using a DSEL for parsing, don't think in those terms.  As another noted, we've also been discussing interface, focusing on simplicity and suitability to the purpose.  Now might be a great time to see how it can be guided to something a little closer to Spirit syntax for that growth path from the simple -- convert -- to the complex -- full Spirit.

> Wouldn't it be better to use the experience the Spirit
> developers/users have
> collected over _years_ (!) and try to find a simpler API on
> top of Spirit
> directly extending from the existing one, certainly while limiting the
> possibilities in favor of a reduced feature set and a simplified usage
> model?

I don't think the Spirit developers have made such an offer previously.  You suggested Spirit syntax before but not like here.  I'm happy to see what can be done on this tack.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.