[boost] Re: Re: Re: FORMAL review of "Output Formatters" - results

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-10-26 14:32:20

"John Torjo" <john.lists_at_[hidden]> wrote in message
news:417CD1ED.604_at_torjo.com...
> >>Reece will redesign it, given the feedback and a new formal review will
> >>take place in about 3 months.
> >
> >
> > Are you also taking back your suggestion that the 2nd review be abbreviated?
It
> > seems to me that the only reason to have a short 2nd review would be if some
> > preliminary conclusions had been reached in the first review. If I recall
>
> I will prefer an abbreviated review. Depending on how much feedback is
> received, I might choose to extend it.

Okay.

> > correctly, there were at least 4 distinct ideas about how the library should
be
> > redsigned, with no clear preference for one alternative among participants
in
> > the review. If, as review manager, you believe there was enough consensus on
> > certain issues or you decide independently that certain solutions are
> > technically
> > best, you should state this in the review result.
> >
> > Here are some of the open issues:
> > - Since renaming is required, what should the new names be?
>
> Renaming can happen at a later time (not now, that is). It can also
> happen during the review. It's happened before. Also, this is relevant
> if the library is accepted.

I agree. I'm just pointing out that this issue was not resolved and therefore
might be expected to take up some time during the second review.

> > - Should the library use locales and/or iword/qword?
>                                                  ^ pword, that is

Yes, pword ;-)

> This is an implementation detail.

Agreed. But implementation details are an important subject for review
discussions.

> > - Should the library be a lightweight facility for debugging or a
full-flegded
> > formatting facility which allows an object to be output in almost any
possible
> > way?

> It should be an in-between.

> >>I would like it on record that I disagree with this decision.<snip> I
> >>still not sure that problem domain doesn't warrant library at all.
> >
> >
> > At the just completed Redmond meeting, the library working group voted to
remove
> > tuple i/o from TR1, partly because of some difficulties with the
specification.
> > But there was unanimous agreement that some standard i/o facility is needed
for
> > all STL containers, and substantial support for a certain degree of
> > customizability.
> >
> > Therefore, I think the best way to procede would be to develop two
proposals,
> > which might be combined into one library:
> >
> > 1. An ultra-lightweight version which could be a candidate for
standardization,
> > providing both input and output and minimal support for user customization.
This
> > version should work by overloading operator<< in namespace std, and be
> > implementable with very little metaprogramming.
>
> For starters, I thinkg you should be able to use boost.serialize.

As I stated in my review, I conceive of the output formatters library as an
inverse to Spirit. I'n many cases loss of information is desirable, so there is
no natural way to support input. However, I'm now proposing  *in addition*  a
lightweight facility that could become part of the standard library. My
impression from sitting in with the library working group is that both input and
output would be desired for such a facility. While I admire Boost.Serialize very
much, and might like to see it standardized, it's obviously not what is needed
to fix the embarrassing lack of stream inserters and extractors for standard
containers.

> Otherwise, I think something very trivial could be:
> - provide support to write an array, with delimeters (open, in-between,
> close).
> - provide support for writing a collection, with delimeters (open,
> in-between, close).
>
> This is very lightweight, and a constraint is that open != in-between
> and close != in-between (so that you can read back an array).
>
> You'll write things like:
>
> std::vector<int> v;
> v.push_back(1); v.push_back(3); v.push_back(4);
>
> std::cout << write(v, "[ %, % ]"); // [ 1, 3, 4 ]
> std::cin >> read(v, "[ %, % ]"); // read back
> std::cout << write(v, "[ %\n% ]"); // [ 1\n3\n4 ]
>
> A facility for escaping strings will also be needed.
>
> I will make some time later this week, and come up with a very
> lightweight version of this.
> (in the meanwhile, I'll also look at Rozental's implementation - maybe
> that's all we need)
>
> And just to make it clear once again:
> The "Output Formatters" library *should not* provide Input facilities
> (Reece, please take note!)

I've written a sample implementation over the weekend which I'll post as soon as
I have time to document it. Sample use:

    // pseudo code initialization:
    vector< list< pair<string, string> > > v =
        { { make_pair("hello", "goodbye"),
            make_pair("morning", "evening"),
            make_pair("cold", "hot") },
          { make_pair("hello", "goodbye"),
            make_pair("morning", "evening"),
            make_pair("cold", "hot") } };

    int flags = punc::indent_after_open |
                punc::break_after_sep;

    cout << punctuate< vector<_> >("[", ",", "]", flags)
         << punctuate< list<_> >("{", ",", "}", flags)
         << punctuate< pair<_, _> >("(", ":", ")")
         << v << "\n";

Output:

    [
        {
            (hello:goodbye),
            (morning:evening),
            (cold:hot)
        },
        {
            (hello:goodbye),
            (morning:evening),
            (cold:hot)
        }
    ]

It provides input and output, but no string-escaping (yet). Right now, a string
is regarded to be complete as soon as an appropriate punctuaion sequence is
encountered.

> > 2. A highly-customizable framework for formatting more-or-less arbitrary
types.
> > This proposal might be seen as an inverse to Spirit. IMO, it's worth
pursuing
> > several of the ideas brought up during the review, to see how they compare.
As
> > much as I'd like to see this happen soon, I think three months is
unrealistic.
> >
>
> It's so funny, during reviews, everyone comes up with his own better
> version of the reviewed library.
>
> Reece's lib has been in the sand-box for so long, and nobody said anything.

I hope you're not directing this remark at me. I've worked with Reece on his
library since before it was in the sandbox. Early on I sent him some sketches of
my ideas for his library, and was hoping to produce a sample implementation.
Unfortunately, I got too busy.

>
> Best,
> John
>

Jonathan