From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Aspect location in expression function.
Date: Mon, 23 May 2022 23:05:12 -0500 [thread overview]
Message-ID: <t6hlhq$vcu$1@dont-email.me> (raw)
In-Reply-To: t5oigj$pag$1@dont-email.me
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3333 bytes --]
"J-P. Rosen" <rosen@adalog.fr> 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 => <very long expression that extends over several lines
here>
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 => <very long expression that extends over several lines
here>;
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.
next prev parent reply other threads:[~2022-05-24 4:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-14 11:47 Aspect location in expression function Blady
2022-05-14 15:40 ` J-P. Rosen
2022-05-24 4:05 ` Randy Brukardt [this message]
2022-05-24 10:01 ` J-P. Rosen
2022-05-25 5:17 ` Randy Brukardt
2022-05-24 18:24 ` G.B.
2022-05-25 5:20 ` Randy Brukardt
2022-05-25 18:45 ` G.B.
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox