Re: Is this expected behavior or not

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 5 Apr 2013 21:02:43 +0200, Stefan.Lucks@uni-weimar.de wrote:

> On Fri, 5 Apr 2013, Dmitry A. Kazakov wrote:
> 
>> On Fri, 5 Apr 2013 16:44:53 +0200, Stefan.Lucks@uni-weimar.de wrote:
> 
>>> But the same is true for N and Z: every in Z has an additive inverse, but
>>> not every number in N. If the non-existence of a multiplicative inverse
>>> would justify different root types for Z and R, why should the
>>> non-existence of an additive inverse not justify different root types for
>>> N and Z (Universal_Positive versus Universal_Integer).
>>
>> That depends solely on the application domain.
> 
> Ada is a general-purpose language.

Yes <=> Ada can be used for most application domains.

> We are discussing Ada's type concept 
> and not any specific application, so there is not "the application domain" 
> anything could possibly depend on.

We are discussing deficiencies of Ada type system, unable to capture
relations between domain specific entities modeled as objects and types.

E.g. few built-in numeric types, which are supposed to fit everything and
expectedly fail, because predefined numbers have properties you might not
need and miss ones you do need. The Op's subtype Prim was a perfect example
of such a failure. Prime numbers are neither additive nor multiplicative.
It is not a group. Yet Prime inherited the interface of a group from base
type (Positive) and there is no way to prohibit this. It also inherited the
order of Positives ('Succ), which is not one of Prime, and, again, there is
no language means for fix that.

> Sure, one of the main strengths of Ada from its beginning is allowing the 
> programmer to define different and intentionally incompatible types with 
> identical representations.

How is representation relevant here? Two incompatible types are
incompatible per programmer's wish, whichever representation they might
have. Representation is an implementation detail.

> But you are actually proposing the opposite: Making different types with 
> different representations intentionally compatible by introducing some 
> universal super-type and then formally deriving the different types from 
> the super-type.

No, I insist that it is up to the programmer to decide whether two types to
become compatible (relative) or not. Character and Wide_Character are
evidently relative. Velocity and Acceleration are not (considering
assignment operation and additive group operations). They are relative
considering multiplication. This is why multiple inheritance is a key
issue.

> Actually another corner stone of Ada has been the language designers' 
> reluctance to introduce implicit conversions between types with different 
> representations.

I disagree. They wanted to prevent the mess of PL/1 where *arbitrary*
conversions were applied to semantically unrelated types. Types like
Character and Wide_Character are semantically related. Conversion from one
to another is perfectly well defined.

> Sure, some cases where implicit conversions take place 
> exist, but only very few. One example is the conversion of constants of 
> type Universal_Something into the right type.

It makes sense in all cases where types are related. This is simply the
definition of a type S being a subtype of T <=> S is substitutable for T.
If representations are different the substitution is done per conversion.
Not a rocket science, really.

And it is all up to the programmer to tell the compiler that S must be
considered a subtype of T, whatever representation both might have is not
language's business.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de