Re: Consider her way -- Re: Dimensionality Checking

["Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>]

"Mark Lundquist" <mlundquist2@attbi.com> wrote:
>>   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?
That facility corresponds to a major general software engineering paradigm.

>  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.

>>   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. Note, that I proposed to use the subtypes and not the
types for expressing of dimensionality.

>> 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.
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.

>  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);
Why "save"? You may use the subtypes for both purposes without any difficulty.
Moreover, these somtimes may be combined nicely; for example a subtype for the 
speed may have the range that corresponds to the maximal speed - either speed
of light, or (in a specific application) the speed of sound.

> 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!
Well, but what is bad here for the dimensionality checking?

>  The subtype is not some abstract property of the object,
Even a subtype without a range? And what is it, in such a case?


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia