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.1008344102.3072.comp.lang.ada@ada.eu.org...
> "Mark Lundquist" <no.spam@getalife.com> wrote:
> >
> > I feel that unit-safety with automatic unit
> > conversion is a concept that is similarly useful and feasible.
>
> I doubt that - the latter. The scaling, that is, employment of the
different
> units for the same magnitude in a program is a relatively rare case. And I
> beleive that the general rule is that all magnitudes in a subroutine
should be
> uniform, that is, a certain unit must be selected for each magnitude, and
all
> values of that magnitude in the subroutine must be expressed using that
selected
> unit.

That's a good principle, and it's easy to obey in cases of self-contained
programs where the entire corpus of source code is under the control of a
single author.  But we also have to consider the case where a program
incorporates foreign libraries.  One of the aims of a language that wants to
encourage reuse should be to facilitate a principle of "minimal coercive
power" for these reusable libraries.  To some extent we always have to
designing "around" the library -- that's not the point; it is still
desirable for libraries to impose the mildest possible requirements on their
clients.  In the case of units, I think it's onerous to have libraries that
say "we do everything in foobar units, and to use it you must either also do
everything in foobar units, or else hand-code whatever conversions you need
to-and-from foobar units and then be sure to apply those conversions to all
parameters and return results."

> Certainly, the values of the magnitude may come from the external sources
> - the parameters and input streams, and those values may be expressed
using
> other units; in those cases the conversions should be performed at the
boundaries:
> all the arguments of a call must be converted to the units required by the
> subroutime called (before or inside an invocation), and the incoming
numbers
> must be converted immediately.

These conversions must be hand-coded.  If you neglect to apply a conversion,
there is no check to catch the error.  And hand-coded conversions to not
automatically compose; you have to hand-code all needed conversions for base
and derived units (vs. defining them for a handful of base units).  Nor are
they reversible, i.e. for interoperability between m and km I would have to
write the conversion going each way rather than simply defining the
relationship between them.

Some people focus on the issue mixing unit systems within a program, that
this is bad practice or whatever.  But that's a red herring -- the ability
to mix unit systems is really not the point.  Often, I would think, for
reasons of scale it might be more convenient for an application to work in a
given unit, but then make use of a function in a library that is written in
terms of some other unit in the same unit system, e.g. mL vs. L.  Unit-safe
programming with automatic conversion allows this without the problems
listed above.  But additionally, the provision for generic formal units
would make possible a much better approach, where a generic function could
be written to be independent of actual units.  You would then end up with
instantiations which perform the calculations without errors introduced by
unnecessary scaling, e.g. going from microns to meters and back again just
because the function was written for meters.

>
> >> 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"
> I think that such additions may lead to Ada++.

You may be right.  I presume by "Ada++" you mean introducing all kinds of
complex entanglements, special-case rules, redundancies and pitfalls.  That
would certainly be to be avoided.

An idea like this unlikely to get anywhere without a very thorough, detailed
and comprehensive proposal.  If I end up trying to write such a proposal,
and it looks like it is headed for "Ada++", I will surely scrap it :-).  I
do not think this is a feature that would be "worth it at any cost".  But I
believe that it could in fact be defined as a clean and orthogonal
enhancement to Ada.

>
> > in this regard (unit abstraction for numeric types).
> By the way, I still don't see an abstraction here. How will you describe
the
> notion of unit as an abstraction? For example "a type is the set of
possible
> values and the set of operations" - and what is a unit?

Well, what is a "value"? :-)  You picked a great example.  The concept of
unit, like that of value, is not "definable" in the language, but that is
not necessary.  You're getting all philosophical about it and making it
harder than it really is :-).  But I certainly do see an abstraction in
units...

> >Where do these unit conversion functions come from?  They must be
> >hand-coded.
> Yes, surely, they must be hand-coded. But as I said above, there are only
two
> kinds of places where those conversions are needed - at the subroutine
calls
> and after input statements. I do not think that the probability of an
error
> there is substantially higher that the probability of a mistake within a
> declaration of the "unit-aware types".

Hmm?  I'll grant you that much, but in my scheme there is zero probability
of an unchecked error resulting from the failure to apply a conversion to a
parameter or return result.

> In my opinion, the main underlying problem with units is that they are all
> relative. There is no absolute unit for a distance, as well as for time,
> mass, resistance etc.

Of course.  Base units are arbitrary, not fundamental to the universe.  I'm
not losin' any sleep over that! :-)  and I don't see how it creates any
problems for my scheme...

Best Regards,

--mark
--

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