From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Aspect location in expression function. Date: Mon, 23 May 2022 23:05:12 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Tue, 24 May 2022 04:05:14 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="1a8d9be57c517cdc89f42c56a5fd1c0a"; logging-data="32158"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19jorxq5V1JZTeuiMGw9zmYiAUt/Jwrows=" Cancel-Lock: sha1:dhQ7F+xvitRUF/AvCVJctCVq2pA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Response X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-MSMail-Priority: Normal Xref: reader02.eternal-september.org comp.lang.ada:63872 List-Id: "J-P. Rosen" wrote in message news:t5oigj$pag$1@dont-email.me... > Le 14/05/2022 à 13:47, Blady a écrit : >> Hello, >> >> I'm puzzled when I want to changed a function body with aspects to an >> expression function, for instance: >> >> function Length (S : Some_Tagged_Tyoe) return Natural >> with Pre => S.Valid >> is >> begin >> return S.Length; >> end; >> >> have to be changed in: >> >> function Length (S : Some_Tagged_Tyoe) return Natural >> is (S.Length) >> with Pre => S.Valid; >> >> The location of the aspect has moved to the end. >> >> I'd like simply replace the begin block by the expression, as: >> >> function Length (S : Some_Tagged_Tyoe) return Natural >> with Pre => S.Valid >> is (S.Length); >> >> What could be any reasons not to permit it? > > What you say is logical if you think of an expression function as a body; > however, it is more like a specification (it can appear in a package spec, > although it can complete a specification), so the place where the aspect > appears makes sense. And it would be confusing to allow the aspect in two > different places. It is the same for separate bodies of subprograms. To make a functioning :LR grammar for Ada, I *had* to allow the aspect specification in both places, and then make one of them illegal. Which is more work than just allowing in either place. So I guess it is a matter of perspective. :-) To the OP: we discussed placement of aspect specifications ad-nausem, as issues like this always were coming up. There is no consistent rule that really works well, because one does not want small things following large sets of aspect specs -- they can get lost and overlooked. For instance, one puts aspect specifications after "is abstract" as otherwise that could be lost after a lengthy precondition expression (and it's too important to be lost). See how that could happen in the following (illegal) declaration: procedure P (A, B ,,,) with Pre => is abstract; So something like this (and "is null" as well) require the Pre at the end: procedure P (A, B ,,,) is abstract with Pre => ; Expression functions generally follow the same rules as the older null procedures, thus they ended up with the same positioning. It's not as obvious a case here, since the return expression can also be long, but we thought it should be consistent. BTW, I don't think there ever is a reason to go from an expression with a normal body to an expression function (assuming the body is legal). A normal body is more readable and less of a hassle during maintenance. The advantage of an expression function is to use it in places where a regular body is not allowed and/or just to be lazy writing the body - neither of which would ever require changing *to* an expression function. Maintenance might require changing *from* an expression function if the body has gotten too complex (for instance, needs a variable declaration), but that generally will require moving the function as well so "ease" of doing so isn't very relevant. Randy.