Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion to finalise interval literals



With admiration and respect, I continue to believe that the standard should require nothing other than containment when converting from one internal or external representation to another. That way, as different libraries are developed and implemented, different standard conforming schemes can be tried and tested in the market place. Those that people like will survive. The others will die, as they should.

And best of all, there can never be any surprises about a containment failure.

Cheers,

Bill




On 6/8/13 6:32 AM, John Pryce wrote:
Jürgen and P1788

On 7 Jun 2013, at 19:02, Jürgen Wolff von Gudenberg wrote:
as already stated in one of my last emails, I think interval literals should not be required. They will involve languages and compilers, and ,hence, augment the workload in dissemination the of standard.

so change the "shall" into a "should"
With respect, I disagree entirely with this and wonder if the draft text doesn't make the purpose of interval literals (ILs) clear enough.

- For some time to come, interval computation will not be integrated
   within a language; Sun Fortran & C++ are an exception.
   Instead it will be provided by a bolt-on library. Interval literals
   give a standard specification for reading (especially) and writing
   intervals -- important both for interactive work and for reading/
   writing text files.

   An interactive user of a program using 1788 ILs will know what interval
   syntax to expect, independent of platform, language and application.

   In absence of this, different libraries would have different ways of
   reading intervals from an external stream. Though not the same, this
   would be similar to the situation of Algol 60, which didn't standardise
   I/O, leading to different I/O systems being provided by each vendor.
   This was a significant contributor to Algol 60 being made obsolete by
   Fortran, which did standardise I/O.

- 1788 IL syntax is not intended to constrain (though it may guide)
   interval syntax within a language. Sun Fortran is not made 1788-non-
   conforming by having a different interval syntax within the language;
   though to be conforming it *would* have to implement text2interval()
   using the 1788 specification. (Of course, it would also have to change
   from the cset model.)

   I find Richard Fateman's Lisp implementation harder to diagnose. Is
   it a library? Or is it part of the language? Or does the structure
   of Lisp systems mean that this is a meaningless distinction?
   Whichever, I continue to say that to conform, the implementation needs
   either to implement text2interval() or to embed its syntax+semantics
   of intervals within the language.

- I think ILs can form the spec of the interchange format, so we don't
   need to define it separately. (Text-based interchange format, that is.
   Do we need to specify a binary one?) Namely, if an IL represents an
   interval that is exactly representable in a given type T, then the T
   version of text2interval() reads it in exactly. And if T is a 754-
   conforming type, it can be written out exactly as an IL using 754's
   hex-significand form for the bounds (for a binary radix) or exact
   decimal (for a decimal radix). This allows both (write then read)
   and (read then write) to be lossless for such types.

Regards

John Pryce