Re: P1788 input/output
On 2013-06-26 13:15:47 +0100, John Pryce wrote:
> (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.
IMHO, P1788 should only specify text2interval, where the argument
needs to be a valid interval literal. An implementation is free
to add other functions that do leading whitespace stripping and/or
suffix stripping, but this is out of scope of P1788.
Moreover it could be said that the behavior of text2interval and
interval2text in non-default locales (for languages that have such
a notion) is unspecified by P1788.
> (2)
> At present it specifies
> - *free-form* input: text2interval(s), no conversion specifier;
> - *formatted* output: interval2text(x, cs), conversion specifier cs required.
I wouldn't say that it is formatted output. Formatted output includes
formats that may not be read back, e.g. if a thousands' grouping
character is used. Perhaps "parameterized output"... At least a
difference should be made with printf.
It should be said that the output string shall have a type-independent
language-defined or implementation-defined Level 1 interpretation, and
containment shall be satisfied. This is necessary to be read back by
text2interval with any destination type.
> 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.
If we don't plan to specify free-form output (I don't think we should,
as this must remain language-defined or implementation-defined, IMHO),
then we don't need it: this is just a language matter. You can mention
that in a footnote.
Also, text2interval and public2interval depend on the return type, but
this type doesn't appear in text2interval(s) and public2interval(s)
since the argument s is just a string. You should write:
text2interval(s,T) / public2interval(s,T)
or
text2interval_T(s) / public2interval_T(s).
Moreover I suppose that if T is a subset of T' and x is an interval
of type T (so that hull_T'(x) = x), it is *not* required that
public2interval(interval2public(x),T') = x
i.e. the behavior of interval2public is strongly type-dependent, not
based on a Level 1 function. But perhaps the above equality should be
recommended.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)