P1788 input/output

[John Pryce <prycejd1@xxxxxxxxxxxxx>]

Folk

At present the I/O clause of P1788 fits on one page, attached. I would like some discussion to improve it before submitting it as a motion.

It is short because it builds on interval literals. Some needed tidying up is marked by comments in red. 

Note there is no mention of "mid-rad form": I have abolished mid-rad, since (offline) discussion with Ned Nedialkov persuaded me that anything useful it can do, "uncertain form" can do just as well.

However recent comments, most from Ned, suggest the I/O clause lacks some important ingredients. Here are some points.

(1) 
It leaves to the implementation the detail of how to read strings from an input stream. But it can be very annoying if it varies between implementations. Suppose I wish to read a decorated interval XX = (xx,dx) from a stream that starts
|    [1.2, 3.4]_monday morning ...
|    ^ (position of stream pointer, = next character to be read)
The | characters are in case mail systems lose whitespace at the start of the line, which they seem to do.

This is an error because "mon" is not a valid decoration name. Where is the stream pointer after it has read XX? It could be any of the marked ^ below:
|    [1.2, 3.4]_monday morning ...
|               ^  ^  ^
depending how the parsing is done, and the method of error recovery; and I'm sure other positions are plausible. Even
|    [1.2, 3.4]_definitely ...
|    ^
which has a valid decoration string "def", isn't trivial. If allowed, it sets xx=[1.2,3.4] and dx=def. But do we demand whitespace after the "def", i.e. it should valid syntax be
|    [1.2, 3.4]_def initely ...

I hesitate to get 1788 into such language-defined matters but maybe we need to say something.

(2) 
At present it specifies
- *free-form* input: text2interval(s), no conversion specifier;
- *formatted* output: interval2text(x, cs), conversion specifier cs required.

I think we need free-form output. Let's make the cs on output optional: omitting it gives some vanilla layout like the specifier %g, in C's fprintf.

Ned's experience shows a need for formatted input, in order to read files laid out like
  1.234    5.678
  2.345    6.789
  3.456    7.890
  ...
(describing the intervals [1.234,5.678]  {2.345,6.789]  [3.456,7.890]  ...)

where one *mustn't* read the numbers into floating point values because that loses enclosure. Instead it must be equivalent to
  text2interval("[1.234,5.678]"), text2interval("[2.345,6.789]"), ...

My feeling: 1788 should not *require* the above feature because it is easy for a user to implement correctly in a couple of lines of code:
   read the numbers as strings
   embed them in '[', ',' ']' characters
   pass the result to text2interval

But maybe we should say implementations *should* provide such a feature?

Regards

John Pryce

Attachment: P1788InputOutput.pdf
Description: Adobe PDF document