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

Re: P1788 input/output



John,

We followed this principle when implementing interval data types in Sun's Fortran: There will be no integer or real syntax- or systematic-feature in standard Fortran 95 that does not have an interval counter part. That is, intervals will not be a second class data type. This required two items to be developed and implemented: interval formats; and "widest need expression evaluation" and its application to I/O. The second is required to guarantee containment in mixed mode expressions involving intervals as well as integers and reals.

I hope that nothing in P1788 will preclude first class interval data types from being implemented in Fortran and other languages.

Thus, while I am not a "language lawyer", when it comes to definitions of terms and constructs having to do with literals used to represent intervals, I think it might be wise to consult and cite the Fortran standard and not just the C and C++ standards.

Cheers,

Bill




On 7/20/13 12:58 PM, John Pryce wrote:
Bill

On 2013 Jul 20, at 16:37, G. William (Bill) Walster wrote:
Regarding I/O and literals, given that Fortran remains the language primarily devoted to numerically intense computing and clearly the language with the most elaborate and flexible I/O syntax and semantics, might it be worthwhile to consider its latest standard in addition to C and C++'s?
Definitely a good idea. Volunteers to do it?

However, the I/O and literals design is fairly language-independent, except for my recent half-baked idea of how the cs conversion specifier might be designed, which is in the C fprintf style. Would you show us some ways in which Fortran-style I/O has advantages for intervals? Implied DOs in I/O are one brilliant feature that is fairly unique to Fortran, but I'm not sure that's relevant to intervals as such.

John Pryce