Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

Cesar Rabak schrieb:

>> procedure
>> Syntactic_Overloading_Example_Based_On_An_Example_By_Bertrand_Meyer is
>>    type Horizontal_Coordinate is new Float;
>>    type Vertical_Coordinate is new Float;
>>    procedure Point(X : Horizontal_Coordinate; Y : Vertical_Coordinate) is
>>    begin
>>       null; --Whatever.
>>    end;
> 
> Here you create two "subtypes" which are only nicknames for Float in
> order to help the Ada compiler to discriminate the signature. BTW, why
> the need of two subtypes for coordinates?

Horizontal_Coordinate and Vertical_Coordinate are specifically
*not* nicknames, not even informally.
Two new types derived from the same ancestor are definitely
*not* only nicknames for Float.  I see you are trying to
come up with an argument about the same literals  providing
values for objects of entirely different types, and that's
certainly formally true and a nice try.  But if you defer to
the programmers, I will, too, and suggest

   X := Vertical_Coordinate'(1.1);

so as to say what they mean.  Et voila,

     21.    X := Vertical_Coordinate'(1.1);
                                   |
        >>> expected type "Horizontal_Coordinate" defined at line 2
        >>> found type "Vertical_Coordinate" defined at line 3


I'm sure Gloucester will speak for himself, but it's tempting
to step in.

(Nitpick: he is introducing two new distinct types,
not subtypes as an Ada subtype is a type with a constraint
as in subset of values that are in the type).

Every one of the tricks you play below in your example
assigns values of literals of anonymous predefined type
'universal_real' to objects of distinct types.  There
is certainly an issue with literals not being silver
bullets.   Yes, some programmers do not define typed
constants of important values. Yes, they are not even
using C's untyped #define, they just sprinkle literals.


> Careful reading of this line of code shows the 'protection' against
> mistakes occurs only after the 'subtype' has been initialized, but this:
> 
>     X := 3.3;  -- for the sake of argument programmer
>     Y := 0.5;  -- wrote the GUI code backwards
>     R := 1.1;
>     Theta := 2.2;
>     Point(X, Y);
>     Point(R, Theta);
> 
> Happy compiler and code runs, albeit with unexpected results...

Well, there is no way to write full application programs in
type systems(*).  But what's your point?  If we add rigor to your
argument then we might just as well have but one type and make
the compilers even happier with that universal type...


(*) except Qi's, I should think.

--
Georg Bauhaus