Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Ada2012 : When to use expression functions rather than function bodies?
22 views
Skip to first unread message
Martin
Dec 16, 2011, 7:25:09 AM12/16/11
to
Are there any good arguments for *not* replacing all simple, single
line functions that don't [directly] access package body state
information with expression functions?
-- Martin
line functions that don't [directly] access package body state
information with expression functions?
-- Martin
Dmitry A. Kazakov
Dec 16, 2011, 8:24:15 AM12/16/11
to
2. Proper encapsulation (to have interface and implementation separated)
3. Re-use (the same function must be refactored)
4. Maintainability (because of 1..3)
5. Safety (proper bodies are defined on the context where they have no
access to the caller's context, otherwise than through parameters)
6. Deployment (proper bodies can be put into a library, have versions etc)
7. It is not Ada
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Adam Beneschan
Dec 16, 2011, 1:03:07 PM12/16/11
to
part of a package specification, and talking about replacing the
declaration with an expression function, then it would usually be a
bad idea to replace it. The visible part should, ideally, express
what the package is intended to accomplish, at a conceptual level. So
unless the expression is, itself, part of the concept (a rare case),
it's an implementation detail that should not be present in the
visible part of a package. A good test here, I think, is: "Is it
possible that at some later point, I may change the expression
returned by an expression function because I've added new features to
the package or because I've changed the implementation to improve its
efficiency or fix problems?" If the answer is yes, then the
expression is probably an implementation detail and not part of the
package's "concept", and the function shouldn't be an expression
function. I think this is approximately what Dmitry means by "proper
encapsulation".
Offhand, I don't see any problem with replacing simple function
*bodies* with expression functions. But I haven't studied the new
rules carefully, so I couldn't tell you if there are some "gotchas" in
the language rules that would cause the semantics or the impact on
other language rules to be different.
In most cases, it's probably OK to replace a function specification in
the *private* part of a package with an expression function if the
body is simple. But the encapsulation argument could still apply if
the function is intended to be usable by child packages.
-- Adam
Martin Dowie
Dec 16, 2011, 3:36:12 PM12/16/11
to
package Foos is
type Foo is tagged private;
...
procedure Bar (Self : in out Foo)
with Pre => Is_Valid (Self);
function Is_Valid (Self : Foo) return Boolean;
...
private
...
function Is_Valid (Self : Foo) return Boolean is (<validate_Self>);
...
end Foos;
There isn't really an expectation that Is_Valid would be of use to a user
of package Foos.
But I guess the same idiom could be used for other 'simple'
functions...public declaration, private expression function implementation,
leaving the package body of more interesting stuff.
-- Martin
--
-- Sent from my iPad
Adam Beneschan
Dec 16, 2011, 4:34:51 PM12/16/11
to
On Dec 16, 12:36 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com>
wrote:
I don't see a problem (from a proper encapsulation standpoint) with
putting the expression function in the private part.
Like I said before, though, I haven't studied the new rules enough to
know whether there could be any other problems caused by the language
rules. Offhand, it seems possible that if the expression involves a
call to a function in another package, there could be cases where
moving the definition from the body to the specification could fail
because a different elaboration order is required.
-- Adam
wrote:
putting the expression function in the private part.
Like I said before, though, I haven't studied the new rules enough to
know whether there could be any other problems caused by the language
rules. Offhand, it seems possible that if the expression involves a
call to a function in another package, there could be cases where
moving the definition from the body to the specification could fail
because a different elaboration order is required.
-- Adam
Jeffrey Carter
Dec 16, 2011, 5:01:08 PM12/16/11
to
--
Jeff Carter
"I like it when the support group complains that they have
insufficient data on mean time to repair bugs in Ada software."
Robert I. Eachus
91
--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---
Adam Beneschan
Dec 16, 2011, 5:52:01 PM12/16/11
to
On Dec 16, 2:01 pm, Jeffrey Carter
ai05s/ai05-0177-1.txt?rev=1.13):
With the advent of pre and postconditions (see AI05-0145-1), and
conditional expressions (see AI05-0147-1), expressions in
specifications are going to grow much larger and become more
complicated. It is important that parts of such expressions can be
abstracted.
Abstraction of expressions is usually done by introducing functions.
However, this puts the expression in the body, rather than the
specification. This has several negative side-effects:
-- Hiding of the expression from the compiler and other tools that
primarily process specifications;
-- Requiring the body to exist in order to do static analysis of the
pre/post conditions (meaning static analysis cannot be performed early
in the development of a system or on the use of skelton [sic]
placeholder packages).
-- Introduction of otherwise unnecessary bodies and/or otherwise
unnecessary
inline body dependencies (increasing system build times).
Apparently the ARG thought this was a good argument. I'm not
endorsing it personally -- I don't have a particular opinion -- but it
appears sensible on its face.
-- Adam
<spam.jrcarter....@spam.not.acm.org> wrote:
> On 12/16/2011 05:25 AM, Martin wrote:
>
> > Are there any good arguments for *not* replacing all simple, single
> > line functions that don't [directly] access package body state
> > information with expression functions?
>
> Are there any good arguments for expression functions?
Quote from AI05-0177-1 (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/
> On 12/16/2011 05:25 AM, Martin wrote:
>
> > Are there any good arguments for *not* replacing all simple, single
> > line functions that don't [directly] access package body state
> > information with expression functions?
>
> Are there any good arguments for expression functions?
ai05s/ai05-0177-1.txt?rev=1.13):
With the advent of pre and postconditions (see AI05-0145-1), and
conditional expressions (see AI05-0147-1), expressions in
specifications are going to grow much larger and become more
complicated. It is important that parts of such expressions can be
abstracted.
Abstraction of expressions is usually done by introducing functions.
However, this puts the expression in the body, rather than the
specification. This has several negative side-effects:
-- Hiding of the expression from the compiler and other tools that
primarily process specifications;
-- Requiring the body to exist in order to do static analysis of the
pre/post conditions (meaning static analysis cannot be performed early
in the development of a system or on the use of skelton [sic]
placeholder packages).
-- Introduction of otherwise unnecessary bodies and/or otherwise
unnecessary
inline body dependencies (increasing system build times).
Apparently the ARG thought this was a good argument. I'm not
endorsing it personally -- I don't have a particular opinion -- but it
appears sensible on its face.
-- Adam
Adam Beneschan
Dec 16, 2011, 6:08:13 PM12/16/11
to
On Dec 16, 1:34 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Dec 16, 12:36 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com>
> wrote:
> On Dec 16, 12:36 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com>
> wrote:
function in the private part of a specification, if the function is an
"implementation detail", is that if the details of the implementation
are mostly in the package body (in procedures or in more complex
functions), then moving some of it arbitrarily to the private part,
which is separate from the package body and is often in a different
source file, can impair readability and maintainability. When a
programmer is trying to maintain a package, either by adding new
features, improving performance, or fixing problems, it's helpful for
related pieces of information about the package's implementation to be
near each other. Otherwise, it's too easy to miss something. And
moving one implementation detail to a package's private part while
other details are still in the body increases the chance of missing
something.
So yes, I think there is a good argument for *not* mechanically moving
all simple functions to the package specification as expression
functions, even into the private part. The programmer needs to think
about readability/maintainability issues such as I've described.
-- Adam
Adam Beneschan
Dec 16, 2011, 6:09:56 PM12/16/11
to
On Dec 16, 2:52 pm, Adam Beneschan <a...@irvine.com> wrote:
>
> Quote from AI05-0177-1 (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/
> ai05s/ai05-0177-1.txt?rev=1.13):
Sorry, Google broke up my link. Hopefully this will work better.
>
> Quote from AI05-0177-1 (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/
> ai05s/ai05-0177-1.txt?rev=1.13):
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0177-1.txt?rev=1.13
-- Adam
Randy Brukardt
Dec 16, 2011, 8:03:46 PM12/16/11
to
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:1s7pzkf4hmdl5.15o0cmwoy5alh$.dlg@40tude.net...
Umm, an expression function is just another (shorter) way to write a
function body, so it hard to imagine that there is any difference. Using
them to replace a function body *in place* is completely harmless.
I suppose you are talking about the use of expression functions directly in
a specification (without an explicit body), which is a totally separate
issue. There, I tend to agree with you in the sense that they ought to be
used in moderation. The intent was to use them for things like accessors for
private components where there is no real value to the separate body.
For those sorts of uses, the issues you talk about above don't arise. (How
could you "refactor" Obj.Field??). Moreover, everything in the private part
is part of the implementation anyway; you're still enforcing that separation
so long as the expression functions are in the private part.
Randy.
news:1s7pzkf4hmdl5.15o0cmwoy5alh$.dlg@40tude.net...
function body, so it hard to imagine that there is any difference. Using
them to replace a function body *in place* is completely harmless.
I suppose you are talking about the use of expression functions directly in
a specification (without an explicit body), which is a totally separate
issue. There, I tend to agree with you in the sense that they ought to be
used in moderation. The intent was to use them for things like accessors for
private components where there is no real value to the separate body.
For those sorts of uses, the issues you talk about above don't arise. (How
could you "refactor" Obj.Field??). Moreover, everything in the private part
is part of the implementation anyway; you're still enforcing that separation
so long as the expression functions are in the private part.
Randy.
Randy Brukardt
Dec 16, 2011, 8:21:45 PM12/16/11
to
"Adam Beneschan" <ad...@irvine.com> wrote in message
news:12acbf57-01fc-43dd...@q9g2000yqe.googlegroups.com...
...
is that there is such a thing as too much encapsulation. The entire point of
preconditions is that they be understandable to the client, so the client
(caller) knows what they must ensure before calling the routine.
You could write all of your preconditions like:
procedure Do_It (A, B : in out Integer)
with Pre => Do_It_Precondition (A, B);
but no one would have any idea what the precondition is. After all, an
important part of the point of preconditions is to change what currently is
specified in English in the comments in a more formal way that can be
checked (statically and dynamically).
So it is best to use as little encapsulation as possible in preconditions
and the like, breaking them down to the primitive operations of the type(s)
involved.
But preconditions can get very long, and the need to simplify them for
readability surely exists. Thus expression functions provide a middle
ground. They're also handy for simple accessor functions (which can give the
effect of read-only components of a private type).
There also is one more fact: an expression function can almost always be
inlined (beware of recursion, though), and that can be done automatically
when it makes sense (no need for pragmas or body dependencies -- inlining is
something the compiler should be deciding upon anyway, it is stupid for
users to have to declare something that should always be done if it makes
sense -- and not be done when it doesn't make sense).
Randy.
news:12acbf57-01fc-43dd...@q9g2000yqe.googlegroups.com...
...
>Apparently the ARG thought this was a good argument. I'm not
>endorsing it personally -- I don't have a particular opinion -- but it
>appears sensible on its face.
One of the things we learned when thinking about Preconditions and the like
>endorsing it personally -- I don't have a particular opinion -- but it
>appears sensible on its face.
is that there is such a thing as too much encapsulation. The entire point of
preconditions is that they be understandable to the client, so the client
(caller) knows what they must ensure before calling the routine.
You could write all of your preconditions like:
procedure Do_It (A, B : in out Integer)
with Pre => Do_It_Precondition (A, B);
but no one would have any idea what the precondition is. After all, an
important part of the point of preconditions is to change what currently is
specified in English in the comments in a more formal way that can be
checked (statically and dynamically).
So it is best to use as little encapsulation as possible in preconditions
and the like, breaking them down to the primitive operations of the type(s)
involved.
But preconditions can get very long, and the need to simplify them for
readability surely exists. Thus expression functions provide a middle
ground. They're also handy for simple accessor functions (which can give the
effect of read-only components of a private type).
There also is one more fact: an expression function can almost always be
inlined (beware of recursion, though), and that can be done automatically
when it makes sense (no need for pragmas or body dependencies -- inlining is
something the compiler should be deciding upon anyway, it is stupid for
users to have to declare something that should always be done if it makes
sense -- and not be done when it doesn't make sense).
Randy.
georg bauhaus
Dec 17, 2011, 7:26:21 AM12/17/11
to
Adam Beneschan <ad...@irvine.com> wrote:
.
>
> In most cases, it's probably OK to replace a function specification in
> the *private* part of a package with an expression function if the
> body is simple. But the encapsulation argument could still apply if
> the function is intended to be usable by child packages.
A pragma Pure is, I think, helpful when
.
>
> In most cases, it's probably OK to replace a function specification in
> the *private* part of a package with an expression function if the
> body is simple. But the encapsulation argument could still apply if
> the function is intended to be usable by child packages.
writing expression functions in particular
if it forces thinking about the kind of
functions one is writing: expression functions that
have effects other than computing
the result value seem out of (some) style.
georg bauhaus
Dec 17, 2011, 7:45:38 AM12/17/11
to
"Randy Brukardt" <ra...@rrsoftware.com> wrote:
.
>
> You could write all of your preconditions like:
>
> procedure Do_It (A, B : in out Integer)
> with Pre => Do_It_Precondition (A, B);
>
> but no one would have any idea what the precondition is.
I'm guessing that Dmitry will suggest
.
>
> You could write all of your preconditions like:
>
> procedure Do_It (A, B : in out Integer)
> with Pre => Do_It_Precondition (A, B);
>
> but no one would have any idea what the precondition is.
Procedure Do_It (A, B: Int_Sats_Pre) with
Pre => True;
will be safer and will convey the idea
of the precondition better: it is in the type system.
Whether this approach is feasible in general
I don't know.
Dmitry A. Kazakov
Dec 17, 2011, 8:11:35 AM12/17/11
to
On 17 Dec 2011 12:45:38 GMT, georg bauhaus wrote:
> "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>> You could write all of your preconditions like:
>>
>> procedure Do_It (A, B : in out Integer)
>> with Pre => Do_It_Precondition (A, B);
>>
>> but no one would have any idea what the precondition is.
>
> I'm guessing that Dmitry will suggest
>
> Procedure Do_It (A, B: Int_Sats_Pre) with
> Pre => True;
>
> will be safer and will convey the idea
> of the precondition better: it is in the type system.
Not really. The key question is whether Do_It_Precondition is statically
checkable. Note also that it is not always possible to break a [true]
precondition into a set of *independent* subtype constraints. As an example
consider:
function "+" (Left, Right : Dimensioned) return Dimensioned;
The precondition here (IFF measurement units have to be checked statically)
is that Left and Right have the same unit.
If the measurement units cannot be checked statically THEN the precondition
is "true" and the contract of "+" includes Unit_Error.
Argument against Do_It_Precondition is same as against a formula:
declarations should include minimum executable code. The language of
declarations (types algebra operations) must be clearly, visibly separated
from the object (executable) language. All cases when executable code slips
into the declarations cause difficulties because of the contexts mismatch,
e.g.
procedure Foo (Default : Integer := Get);
-- What is the default here? When the default is read from standard
-- input?
Pure and static expressions are OK because the context is irrelevant.
> "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>> You could write all of your preconditions like:
>>
>> procedure Do_It (A, B : in out Integer)
>> with Pre => Do_It_Precondition (A, B);
>>
>> but no one would have any idea what the precondition is.
>
> I'm guessing that Dmitry will suggest
>
> Procedure Do_It (A, B: Int_Sats_Pre) with
> Pre => True;
>
> will be safer and will convey the idea
> of the precondition better: it is in the type system.
checkable. Note also that it is not always possible to break a [true]
precondition into a set of *independent* subtype constraints. As an example
consider:
function "+" (Left, Right : Dimensioned) return Dimensioned;
The precondition here (IFF measurement units have to be checked statically)
is that Left and Right have the same unit.
If the measurement units cannot be checked statically THEN the precondition
is "true" and the contract of "+" includes Unit_Error.
Argument against Do_It_Precondition is same as against a formula:
declarations should include minimum executable code. The language of
declarations (types algebra operations) must be clearly, visibly separated
from the object (executable) language. All cases when executable code slips
into the declarations cause difficulties because of the contexts mismatch,
e.g.
procedure Foo (Default : Integer := Get);
-- What is the default here? When the default is read from standard
-- input?
Pure and static expressions are OK because the context is irrelevant.
Randy Brukardt
Dec 19, 2011, 6:34:42 PM12/19/11
to
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:1xbajufyxdf4j.1moa6g6ouhykk$.dlg@40tude.net...
> On 17 Dec 2011 12:45:38 GMT, georg bauhaus wrote:
...
>> I'm guessing that Dmitry will suggest
>>
>> Procedure Do_It (A, B: Int_Sats_Pre) with
>> Pre => True;
>>
>> will be safer and will convey the idea
>> of the precondition better: it is in the type system.
>
> Not really. The key question is whether Do_It_Precondition is statically
> checkable. Note also that it is not always possible to break a [true]
> precondition into a set of *independent* subtype constraints.
Right. We had this (sub)discussion in the ARG. It seemed better to extend
>>
>> Procedure Do_It (A, B: Int_Sats_Pre) with
>> Pre => True;
>>
>> will be safer and will convey the idea
>> of the precondition better: it is in the type system.
>
> Not really. The key question is whether Do_It_Precondition is statically
> checkable. Note also that it is not always possible to break a [true]
> precondition into a set of *independent* subtype constraints.
subtype constraints for parameters rather than the heavier mechanism of
preconditions. But the counter argument is that a constraint can act only on
a single parameter, while a precondition might involve multiple parameters.
Dmitry shows a good example.
BTW, we recently added a rule stating that it is a bounded error to call a
function from a contract (precondition, predicate, etc.) that has a side
effect that changes the value of some other contract of the same evaluation.
The latter part is a sop to the people who insist that we have to support
"benign" side-effects (such as "memo functions"). (IMHO, there are no benign
side-effects, but there are strong opinions to the contrary out there.)
The effect is that the vast majority of contracts will be "pure"
expressions, so Dmitry will be happier. (The state-of-the-art will not allow
static checking of these things today in general, but as the technology
improves that should become possible without having to rewrite your code).
Randy.
0 new messages