11 ms·

Coming from Ada and its bounded integer and floating point (and fixed points, in the standard) operations defined by type, with explicit conversions, I disagree

Coming from Ada and its bounded integer and floating point (and fixed points, in the standard) operations defined by type, with explicit conversions, I disagree. The correct typing of variables of physical characteristics and their operators has saved my ass so many times, and the use of static and runtime checks is a boon in scientific code. Sadly our internal math library isn't amenable to dimensional analysis, or it would also be another great bug buster. Look up 'gnat' https://gmpreussner.com/research/dimensional-analysis-in-programming-languages#ada https://gmpreussner.com/research/dimensional-analysis-in-pro... and follow the links. Of course nobody prevents you from using Float, Long_Float, Integer everywhere, but it is actually discouraged. Define a specific type. Is it a count, a speed, a quantity of apples, a modular value (i.e. you actually want wraparound semantics), what is its minimal value, its maximum value... The actual binary representation is more of an implementation detail (and can be coerced to do many, many things through 'aspects' or pragmas or just representation clauses. If I could change one thing there, it's the operator visibility rules, which a perennial compaibt of the Ada developer. But, to dissent from my Adaist brethren I'd ask the standard to go to more explicit operator choice. Make it explicit in the code and for those with RSI make the IDE do the inference and print it in the darned code. Please?

cwzwarich 4y ago
As far as I can tell, the correct way to handle units of measurement in a programming language is by extending unification to abelian groups, as in Andrew Kennedy's work that was later implemented in F#: https://www.microsoft.com/en-us/research/publication/relational-parametricity-and-units-of-measure/ https://www.microsoft.com/en-us/research/publication/relatio... This seems superior to the GNAT solution. And support for dimensionality is somewhat orthogonal to the ergonomics of converting e.g. a u32 to a u64 that comes up in systems programming.
- touisteur 4y ago
  You're right that it is orthogonal to the size of the variable, but thinking in bounds, precision, and yes, types (that can carry many notions, including dimensionality) is more interesting, to me, than 'just' u32 to u64. In my experience, being prompted to think about what you actually mean and have a tool to express it and check it is a good way to write understandable and correct code.

cwzwarich 4y ago

As far as I can tell, the correct way to handle units of measurement in a programming language is by extending unification to abelian groups, as in Andrew Kennedy's work that was later implemented in F#: https://www.microsoft.com/en-us/research/publication/relational-parametricity-and-units-of-measure/ https://www.microsoft.com/en-us/research/publication/relatio... This seems superior to the GNAT solution. And support for dimensionality is somewhat orthogonal to the ergonomics of converting e.g. a u32 to a u64 that comes up in systems programming.

touisteur 4y ago
You're right that it is orthogonal to the size of the variable, but thinking in bounds, precision, and yes, types (that can carry many notions, including dimensionality) is more interesting, to me, than 'just' u32 to u64. In my experience, being prompted to think about what you actually mean and have a tool to express it and check it is a good way to write understandable and correct code.