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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable 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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada 2012 Constraints (WRT an Ada IR) Date: Wed, 21 Dec 2016 16:56:35 +0100 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: s3c6wwRqkurrfTZpuYYZ+w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Mozilla-News-Host: news://news.aioe.org Xref: news.eternal-september.org comp.lang.ada:32936 Date: 2016-12-21T16:56:35+01:00 List-Id: On 2016-12-21 01:50, Randy Brukardt wrote: > In any case, some part of the execution of a subprogram call has to be > evaluated at the call site, since the details of the actual parameters > cannot be part of the body (they'll be different for every call). And those > evaluations can raise exceptions. This is all OK. > So the only question is precisely where > the line is drawn, and that is only important in that it is precisely > defined - the exact definition doesn't matter. The line is drawn at the [sub]type border. Once the parameter is of the nominal [sub]type it is the body-in-effect. Once the out parameter or result changes the [sub]type it is out of the body-in-effect. > To take an example. The rule is that all parameter expressions are > implicitly converted to the type/subtype of the parameter in a call. > > X : constant Integer := 0; > procedure Foo (P : Positive); > > Foo (10 / X); -- Clearly, the evaluation of the call raises > Contraint_Error (for a divide-by-zero). The body never executes. > > Foo (Positive(X)); -- Clearly, the evalation of the call raises > Constraint_Error (for a conversion failure). The body never executes. > > Foo (X); -- Raises Constraint_Error because the implicit conversion is > the same as the explicit onew given above. Again, the body never executes. > > My understanding is that the designers of Ada 83 wanted the semantics of the > last two calls to be exactly the same, as the former is just the explicit > version of the implicit conversion of the second call. It would be unusual > if they executed differently at all. (On top of which, the rules for > derivation include similar implicit conversions, and those conversions need > to work the same as similar code written explicitly.) None of that has ever > been changed since Ada 83. The effect of two last calls maybe same, the attributed semantics is not. From the POV of a typed system the last call must be to an Integer operation composed from the original Foo and a type conversion Integer->Positive. A composition of two operations is exactly calling one and then another. No difference. Theoretically we should be able to pass Integer Foo as a parameter to another subprogram or generic expecting procedure (X : Integer). This is rightfully prevented for Positive Foo by subtype conformance. That would be a case where semantic difference would play a role. > It has to be true, there is no alternative. You just want to move the line a > bit, but there is no advantage to doing that. But it necessarily would > produce worse code (an Ada compiler is not allowed to look into bodies > outside of Inline), and it also would make implicit and explicit conversions > work differently. I don't see why they should. Nothing requires the body-in-effect be one chunk of code. The compiler is free to inline any of its parts. >>> I don't follow this at all. There's nothing different about the built-in >>> extensions (mostly streams) from any other subprogram. >> >> Certainly checks decorating user-defined bodies of stream attributes for >> some components may raise something. According to the nonsense you are >> defending, these would not be the result of the body, being propagated >> right from the middle of its execution... > > The result of *which* body? In this case, (as in all cases involving > implicit things) there are implicit calls of the original bodies. There's no > actual combining of routines (that would be problematic both semantically > and implementationally). And of course implicit calls follow the rules of > other calls. No body no implementation, what is being called? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de