[J3] 18-156

[Van Snyder]

On Mon, 2018-02-26 at 21:56 -0800, Damian Rouson wrote:
> I could be dissuaded form supporting units if the cost is higher than
> the two major feature sets that clearly have the broadest community
> support

I've actually thought a bit about implementation.  I've written small
compilers and interpreters for small languages, but never anything as
ambitions as a Fortran compiler.  I taught compiler construction classes
at a university for seventeen years as the capstone of the software
engineering sequence.  Being an undergraduate course, it was necessarily
much less ambitions that a course about real compilers for comprehensive
languages.  That being said, I can see avenues to approach at least two
difficult problems.

Unit definitions are unique by their defining statements, not their
structure, just like non-sequence types.  Processors know how to check
this uniqueness, even in the face of renaming during use association.
I'm pretty sure it's easier than checking equivalence by structure.

The draft TS proposes that units participate in generic resolution, that
a procedure that has a dummy argument with units is required to have
explicit interface where it's referenced, that a procedure reference
with an actual argument that has units requires the referenced procedure
to have explicit interrace, and that units of actual and dummy arguments
are required to match.  Resolution and checking are no different from
the situation for kind type parameters.  Processors already have to deal
with multiple kind type parameters, so adding units to kind type
parameters for real entities is not a tremendously new problem.

Calculating and checking units in expressions and assignment are new
problems, but not terribly difficult.  Producing unit names on output
and checking units on input are new problems, but not terribly
difficult.

No hidden code generation is required.