Ada2012 : When to use expression functions rather than function bodies?

Ada2012 : When to use expression functions rather than function bodies?

[Martin]

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

Re: Ada2012 : When to use expression functions rather than function bodies?

[Dmitry A. Kazakov]

On Fri, 16 Dec 2011 04:25:09 -0800 (PST), 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?

1. Readability
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

Re: Ada2012 : When to use expression functions rather than function bodies?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1s7pzkf4hmdl5.15o0cmwoy5alh$.dlg@40tude.net...
> On Fri, 16 Dec 2011 04:25:09 -0800 (PST), 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?
>
> 1. Readability
> 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

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.

Re: Ada2012 : When to use expression functions rather than function bodies?

[Adam Beneschan]

On Dec 16, 4:25 am, Martin <mar...@thedowies.com> 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?

If you're talking about a function that is declared in the visible
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

Re: Ada2012 : When to use expression functions rather than function bodies?

[Martin Dowie]

Adam Beneschan <adam@irvine.com> wrote:
> On Dec 16, 4:25 am, Martin <mar...@thedowies.com> 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?
> 
> If you're talking about a function that is declared in the visible
> 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

The most common usage I can image is functions used in Pre/Post conditions:

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

Re: Ada2012 : When to use expression functions rather than function bodies?

[Adam Beneschan]

On Dec 16, 12:36 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com>
wrote:
> Adam Beneschan <a...@irvine.com> wrote:
> > On Dec 16, 4:25 am, Martin <mar...@thedowies.com> 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?
>
> > If you're talking about a function that is declared in the visible
> > 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
>
> The most common usage I can image is functions used in Pre/Post conditions:
>
> 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.

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

Re: Ada2012 : When to use expression functions rather than function bodies?

[Adam Beneschan]

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:

I wrote:

> > Adam Beneschan <a...@irvine.com> wrote:
> > > On Dec 16, 4:25 am, Martin <mar...@thedowies.com> 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?
>
> > > If you're talking about a function that is declared in the visible
> > > 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
>
> > The most common usage I can image is functions used in Pre/Post conditions:
>
> > 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.
>
> 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.

On thinking about it further: A good reason *not* to put an expression
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

Re: Ada2012 : When to use expression functions rather than function bodies?

[georg bauhaus]

Adam Beneschan <adam@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
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.

Re: Ada2012 : When to use expression functions rather than function bodies?

[Jeffrey Carter]

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?

-- 
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 news@netfront.net ---

Re: Ada2012 : When to use expression functions rather than function bodies?

[Adam Beneschan]

On Dec 16, 2:01 pm, Jeffrey Carter
<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/
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

Re: Ada2012 : When to use expression functions rather than function bodies?

[Adam Beneschan]

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.

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0177-1.txt?rev=1.13

                 -- Adam

Re: Ada2012 : When to use expression functions rather than function bodies?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:12acbf57-01fc-43dd-8881-d39c2a63146b@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 
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.

Re: Ada2012 : When to use expression functions rather than function bodies?

[georg bauhaus]

"Randy Brukardt" <randy@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.
Whether this approach is feasible in general
I don't know.

Re: Ada2012 : When to use expression functions rather than function bodies?

[Dmitry A. Kazakov]

On 17 Dec 2011 12:45:38 GMT, georg bauhaus wrote:

> "Randy Brukardt" <randy@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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada2012 : When to use expression functions rather than function bodies?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@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 
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.