From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Fri, 5 Apr 2013 21:34:16 +0200 Organization: cbb software GmbH Message-ID: <1xbow8ojtmac9.1sfor8ytiplgx.dlg@40tude.net> References: <1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net> <3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net> <1gkxiwepaxvtt$.u3ly33rbwthf.dlg@40tude.net> <1fmcdkj58brky.bjedt0pr39cd$.dlg@40tude.net> <1bj564vat3q1j$.1s4d00rlzx4ux$.dlg@40tude.net> <1cfhriq4xpg9s$.3yl33z705wpn$.dlg@40tude.net> <16wai67izvmu5.13yz864sx1cqd$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: rHWOzyHApalsT5sEUcbvVQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:14878 Date: 2013-04-05T21:34:16+02:00 List-Id: 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