Re: Consider her way -- Re: Dimensionality Checking

["Mark Lundquist" <mlundquist2@attbi.com>]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.1008097622.26173.comp.lang.ada@ada.eu.org...
>
>[snip...]
>   Now let's recall the fact that the Ada is not a problem-oriented
language,
> but rather a "superassembler". It intentionally and carefully avoids all
> paradigms that aren't closely related to the real computer architectures
or
> to the general software engineering, even if those paradigms are heavily
used
> in some significant application area. (Note that I'm speaking here about
the
> paradigms; the data representation issues are another matter, that is a
natural
> job for an assembler.)
>   Obviously, the dimensionality paradigm is one of the kind that Ada
avoids:
> it belongs neither to a computer architecture nor to the general software
> engineering, but to the particular application area, no matter how
significant
> it is in the real world. Therefore Ada most probably will not take any
move
> to support it directly.

Well OK, but then how do you explain Ada's type system?  If the language did
not
abstract types away from its own "machine model", then wouldn't we have
C-style type-equivalence instead?  Instead, in Ada we have the idea that
"number of lines in a file" and "number of cows" can be different types.
Isn't that pretty abstract for a "superassembler"?

>
>   The proper way to do the dimensional/unit analysis for the Ada programs
is
> to use the ASIS and some suitable language processor [snip...]

For one thing, you would still have to code all of of your own unit
conversions.  See other posts in this thread, keywords "combinatoric" and
"explosion" :-)
(Hmmm, "explosion" might pick up that other post about pajamas being
inflammable, or inflatable, or whatever that was... :-)

>
>   Finally, I'll try to explain why the subtypes, and not the types, are
the
> natural carriers for the dimensionality info. Briefly, with the physical
> magnitudes, all the dimensionalities are imaginary, and only the
repetition
> count within some underlying measurement process is real. That count is
obviously
> dimensionless. In fact, a dimension of physical magnitude is the
abstraction
> for the class of the instruments with which we can measure the magnitude.

Are you just trying to say that we have base units which are arbitrary, and
derived units based on those?

>   If you do not like such vague metaphysical arguments then consider the
> following question: if X and X*X belong to the different types, how will
you
> treat (interpret) the usual approximations by the Taylor series?

Well, I think you're almost right here... you don't have to think about
Taylor series to see the problem.  The fundamental glitch is that
unit-safety takes you from a numeric system that is closed under
multiplication to one that is not.  Every expression in Ada has a value; if
X is of a "dimensioned type" as we have been considering, then what is the
type of the expression 'X * X'?  So you're right that in the "dimensioned
type" approach there has to be some relationship between the types, but it
would be absolutely wrong to co-opt subtyping for this.  For one, we want to
save subtypes for what they are already used for (constraint checks); but
more fundamentally, it just does not make sense.  Given a subtype and a
value, you can tell whether the value is in the subtype!  The subtype is not
some abstract property of the object, which is what dimensions/units would
be.

Best Regards,
Mark