Re: Consider her way -- Re: Dimensionality Checking

["Mark Lundquist" <no.spam@getalife.com>]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.1008201902.27048.comp.lang.ada@ada.eu.org...
> "Mark Lundquist" <mlundquist2@nospam.com> wrote:
> >>   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?
> That facility corresponds to a major general software engineering
paradigm.

But it has not always been so with strong typing.  I submit that it became
"general" because it was useful in practice and feasible for implementation
in a programming language.  I feel that unit-safety with automatic unit
conversion is a concept that is similarly useful and feasible.

>
> >  If the language did not
> >abstract types away from its own "machine model", then wouldn't we have
> >C-style type-equivalence instead?
> Certainly yes.
>
> >  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"?
> Not at all. It is too abstract for an assembler (such as C, for example),
but
> Ada is a "superassembler", which facilitates dealing with the general
software
> engineering enviromnent, besides of the real computer architectures.

I agree.  My position is, let's make it a little more "super" in this regard
(unit abstraction for numeric types).

>
> >>   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.
> Why? Two distinct subtypes of the same type may be used together in an
expression
> without any conversion.

True, unfortunately for your scheme... if a quantity expressed in grams is
used in an expression where a quantity expressed in kilograms was meant, and
they are both the same type (because they are of the same dimensionality --
though they may be different subtypes, I expect for the benefit of your
checking metalanguage?), then no incompatibility is detected by the
compiler.  Notwithstanding the detection issue, to correct the
incompatibility you must run the value through a unit (scaling) conversion
(which I understand would not entail a type conversion in your scheme).
Where do these unit conversion functions come from?  They must be
hand-coded.

> In my opinion, the unit-safety may be based on the type system only for
the
> relatively simple situations, which is essentially linear. The typical
example
> of "apples and oranges" falls in that category.

I agree completely, in the context of trying to use the existing Ada typing
system to effect unit-safety and unit conversions.  These cannot be subsumed
by the current type system.  My proposal would be to build unit-awareness
into the type system.  That would completely change the outlook.  You would
not think of unit-safety as being "based on" the type system -- instead,
aspects of the semantics of the type system would be based on unit-safety!

Best regards,
-- mark

--
--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting