 |
 |
On Sat, 2016-07-09 at 14:58 -0400, Vipul Parekh wrote: > 1. You note, "The reasons given by the vendors are.. it's too hard " > and then you remark, "it isn't -- I've laid out a roadmap for how to > do it, and nobody commented on it." How exactly do you know it is NOT > too hard? Can you please elaborate? I've heard on this mailing list > any change or addition to the "type system" in Fortran is highly > complicated. I inquired of ENUM functionality on Fortran forums (a > feature supported over a decade or more by all programming languages > that are casting Fortran aside in technical computing area, and the > response on this mailing list (you were the only exception) was so > luddite and disappointing, to say the least. It was as if the query > was of some complexity beyond the theory of everything. To me, your > proposal intuitively feels hard but I expect I'm mistaken. So I am > curious to learn how your proposal doesn't affect the "type system" > and keen to hear more on the "it isn't" comment of yours. I believe the measurement unit of a variable can be represented internally by the processor in exactly the same way that kind type parameters are represented. Processors already know how to handle multiple type parameters, so this ought not to inflict any significant trauma on the type system. Generic resolution, and checking type, kind, rank, and unit consistency for argument correspondence, is then automatically carried out by existing mechanisms. Again, no significant trauma for the type system. No code generation is involved. Checking and computing units of expressions isn't much more difficult than checking and computing types and kinds of expressions. Both involve "evaluation" of the expression by a set of recursive functions (or one function with a SELECT CASE construct). No code generation is involved. Conversion functions are generated by declarations of conversion units. A family of units related by conversions can be represented by an undirected graph, and its transitive closure, where each edge has two labels, one being the A-B conversion, and the other its inverse. A unit family generates several functions, two for each edge in its relationship graph, times the number of real kinds supported by the processor. For example, a temperature family might have an atomic unit of Kelvin, and conversion units of Rankine, Celsius, and Fahrenheit. The processor needs to calculate the transitive closure of the relationship graph, in order to produce conversions between all pairs of units in the family, in this case twelve functions, times the number of kinds of real that the processor supports, but this is a trivial problem, probably less than one page of code. The proposal allows a generic name and a unit name to be the same. This is not a different problem from allowing a generic name and a type name to be the same. You can call this "code generation" if you wish, but it could happen during or very shortly after parsing. The functions are trivial, of the form f(u) = a*u+b, with "a" and and "b" constant and "a" nonzero, so the inverse is trivial too. I assume the processor has mastered constant folding. Hopefully, they'll be inlined where they're applied, but the proposal is silent on this score. That leaves formatted I/O. During input, if a "U" edit descriptor appears, it works like an "A" edit descriptor to read the name of the unit of the previous value. Once the name is in hand, the runtime support routine checks whether it's exactly the same, in the same family (in which case it converts the value), or announces an error. This "code generation" is in the runtime support library, with perhaps a tiny bit of help from the processor to connect the local names of conversion functions to the possible set of input strings. This doesn't seem to be terribly difficult. During output, if a "U" edit descriptor appears, the name of the unit of the variable is output, as if by an "A" edit descriptor. This is even easier than input.