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 X-Google-Thread: 103376,628d2a493f1e203d X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!atl-c05.usenetserver.com!news.usenetserver.com!cycny01.gnilink.net!hwmnpeer01.lga!hwmnpeer01.ams!news.highwinds-media.com!feed.xsnews.nl!feeder.xsnews.nl!tudelft.nl!txtfeed2.tudelft.nl!amsnews11.chello.com!newsfeed01.chello.at!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Subtype conformance... not what I was expecting. Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <44c6db66$0$2928$4d3efbfe@news.sover.net> <44c77cf0$0$2917$4d3efbfe@news.sover.net> Date: Wed, 26 Jul 2006 20:40:10 +0200 Message-ID: NNTP-Posting-Date: 26 Jul 2006 20:40:00 MEST NNTP-Posting-Host: d08e0a1c.newsread2.arcor-online.net X-Trace: DXC=K?HZ6GTcej8CDTkn::RD0?Q5U85hF6f;4jW\KbG]kaM8U7^]5?JhlB>EZ3I>[oU0U2[6LHn;2LCV>[ On Wed, 26 Jul 2006 10:32:20 -0400, Peter C. Chapin wrote: > Dmitry A. Kazakov wrote: > >>> procedure Check is >>> subtype Narrow is Integer range -10..10; >>> type Function_Ptr is access function(X : Narrow) return Integer; >>> >>> function F(Para : Integer) return Narrow is >>> begin >>> return Para; >>> end F; >>> >>> G : Function_Ptr := F'Access; >>> Result : Integer; >>> begin >>> Result := G(0); >>> end Check; >>> > > [snip] > >> The semantic of "subtype" in Ada is "same type." So if you allow Narrow to >> appear in place of Integer, you must also allow the reverse: >> >> subtype Narrow is Integer range -10..10; >> type Function_Ptr is access function(X : Narrow) return Narrow; >> function F(Para : Integer) return Integer; >> -- Constraint_Error-unsafe >> >> If you wanted a one-way road, you'd need function(X : Narrow) return >> Integer be an override of some primitive subprogram of Integer. That would >> make you able to legally judge about conformance to *class* (Narrow <: >> Integer). But that works for only operations defined on the class. >> Unfortunately Ada does not have either Integer'Class or Narrow'Class. > > Hmmm. I'll have to think about this a little; I don't quite follow you > right now. Consider this > > subtype Narrow is Integer range -10..10; > X : Integer; > Y : Narrow; > ... > X := Y; > Y := X; -- Might raise Constraint_Error. > > Even though one statement is Constraint_Error-unsafe, both are legal. > However, I don't think this is the point I was trying to make. When I do > G := F'Access (in my original example) it is type safe in that I can't > do anything with G that would cause a problem for F. I might get a > Constraint_Error when G's arguments are evaluated or when G's return > value is used but no such error can occur because the actual underlying > function is actually F. Yes it is type-safe, and one could allow type-conformant subroutines as actuals. This would probably impose some minor distributed overhead, I can only guess if that was the reason. A similar case is requeue statement, which also requires subtype-conformance. My point was just, that there is no good choice in-between. It should be either type- or subtype-conformant. > Using the notation common in functional languages, let F : t1 -> t2 and > G : t1' -> t2'. Then t1 -> t2 is a subtype of t1' -> t2' (that is, > t1->t2 <: t1'->t2') iff t2 <: t2' and t1' <: t1. In this case I realize > that G is an access type but it "feels" like a function when it is used. > Since I'm trying to use F where G is expected and since F and G have the > proper subtype relationship to each other one might suppose that the > above rule would be obeyed. Yes, this is close to my view on the issue of subtyping. If t1' is substitutable (=compiler accepts it) in F as an in parameter, that means, in my view, that t1' inherits F from t1 and so t1' t2' inherits F The inherited F is F', with a different profile. G is type conformant to F', but not to F. So it should be substitutable for t1'Class -> t2'Class, but not for t1 -> t2. This is a possible way to unify "subtype" and "is new ... with" under one roof, and also have a fine control over substitution (t1 vs. t1'Class). ------------- (1) We have to distinguish