From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 14 Feb 93 19:55:08 GMT
From: agate!usenet.ins.cwru.edu!howland.reston.ans.net!usc!news.cerf.net!shrike
.irvine.com!adam@ucbvax.Berkeley.EDU  (Adam Beneschan)
Subject: Re: What's the difference between...
Message-ID: <C2GFBx.GJH@irvine.com>
List-Id: <comp.lang.ada>

In article <75591@cup.portal.com> R_Tim_Coslet@cup.portal.com writes:

> In Article: <1993Feb13.191810.4452@inmet.camb.inmet.com>
>         stt@spock.camb.inmet.com (Tucker Taft) Wrote:
> >The important point (which you and others have already made) has
> >to do with static semantics, not representation.  Operands of distinct types
> >cannot be mistakenly combined using the predefined operators or
> >assignment.  Explicit type conversion is required (of course
> >that's a bit annoying for multiplication -- we never did get
> >around to putting full support for "units" into Ada).

> Actually, if you know you are going to be multiplying mixed types
> (e.g. APPLES in a crate by CRATES to get APPLES in a shipment) just
> define a new multiply operator on the mixed types so the "conversion"
> is hidden and "units" are enforced by the compiler.
>
>                                         R. Tim Coslet

This only solves part of the problem, though.  It's no problem to
define this function: 

    function "*" (left : APPLES;  right : CRATES) return APPLES_IN_SHIPMENT;

But ideally, you'd like a way to prevent the programmer from doing
something dumb like multiplying apples and apples.

    type APPLES is new FLOAT;
    x, y, z : APPLES;

    z := x * y;

This last statement, of course, makes no sense in real life, but it's
allowed in Ada.  You could try something cute like redefining "*":

    function "*" (left, right : APPLES) return APPLES is
    begin
        raise PROGRAM_ERROR;
        return 0.0;     -- Ada won't let us write a function that just raises
                        -- an exception without returning anything!
    end "*";

But the error would not be caught until runtime, unless you have an
optimizer that detects this situation or your compiler supports a
pragma that causes a warning message to be displayed when "*" is used
improperly.  Even more annoying:

    type DISTANCE is new FLOAT;
    type SQUARE_DISTANCE is new FLOAT;

    function "*" (x, y : DISTANCE) return SQUARE_DISTANCE;
    function "/" (x : SQUARE_DISTANCE;  y : DISTANCE) return DISTANCE;

    function "*" (x, y : DISTANCE) return DISTANCE;
        -- implemented as an exception raise
    function "/" (x, y : DISTANCE) return DISTANCE;
        -- implemented as an exception raise

    ...

    d1, d2, d3, d4 : DISTANCE;

    ...
   
    d1 := (d2 * d3) / d4;

This is an example you would like to see be legal, since it does make
sense in terms of physics.  But Ada will, I believe, think the
expression is ambiguous.  Which "*" do you use for d2 * d3?  The one
that returns SQUARE_DISTANCE, or the one that returns DISTANCE and
raises an exception?  There's no way for the compiler to tell, so
you'll get an error at compile time.  In this case, you really need
the ability to *delete* the standard "*" function, instead of just
coding it as a function that raises PROGRAM_ERROR.  Does 9X support
this type of feature?

By the way, you can get around this particular problem like this:

   d1 := SQUARE_DISTANCE'(d2 * d3) / d4;

                                -- Adam