Re: how pure are functions?

Re: how pure are functions?

[Mark A Biggar]

In article <43123@as0c.sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) writes:
>    Are they free from internal state?
>No.

I would like to argue that the answer here should be YES.  Ada doesn't 
include a concept similar to C static variables, so any state kept for
an Ada function must be stored in a varible external to the function.
More then likely that variable is only visible in the body of the package
that defines the function and so is invisible to the user of the function,
but strictly the function itself has no "internal" state.  It can be argued
that in Ada only packages and tasks have "internal" state.

--
Mark Biggar
mab@wdl1.wdl.loral.com

Re: how pure are functions?

[Michal Young]

In reply to: 

>    Are they free from internal state?
>No.

Mark Biggar says: 
> More then likely that variable is only visible in the body of the package
> that defines the function and so is invisible to the user of the function,
> but strictly the function itself has no "internal" state. 

This is true, strictly speaking, but from the viewpoint of a user,
verifier, or compiler, Ada functions do not appear to be stateless.
For instance, one cannot generally substitute 2*f(x) for f(x) + f(x).
There are good practical reasons for not insisting that every
"function" be a pure function, but it would be quite helpful if the
language provided some way to indicate that certain "functions" were
actually functions in the mathematical sense.

--Michal Young
-- 
Michal Young

Re: how pure are functions?

[P. Singleton]

>From article <18363@ector.cs.purdue.edu>, by young@cs.purdue.EDU (Michal Young
):

> Mark Biggar says: 

>> More then likely that variable is only visible in the body of the package
>> that defines the function and so is invisible to the user of the function,
>> but strictly the function itself has no "internal" state. 
 
> This is true, strictly speaking, but from the viewpoint of a user,
> verifier, or compiler, Ada functions do not appear to be stateless.
> For instance, one cannot generally substitute 2*f(x) for f(x) + f(x).

Yes, that nicely exemplifies what I meant by "referential transparency",
which was: that the value of a function is determined *only* by its
arguments, and not by the history of execution, and so the compiler can
symbolically manipulate the program (e.g. transform it for efficiency, or
otherwise partially evaluate it, or reason about its correctness, etc.).
Also it should be free from side-effects (as well as the aforementioned
side-infects).

> There are good practical reasons for not insisting that every
> "function" be a pure function, but it would be quite helpful if the
> language provided some way to indicate that certain "functions" were
> actually functions in the mathematical sense.

Yes, I hoped that the distinction of "functions" from the honestly-named
"value-returning procedures", but I am told that this distinction is
obsolete.
----
  __   __    Paul Singleton (Mr)           JANET: paul@uk.ac.keele.cs
 |__) (__    Computer Science Dept.        other: paul@cs.keele.ac.uk
 |  .  __).  Keele University, Newcastle,    tel: +44 (0)782 621111 x7355
             Staffs ST5 5BG, ENGLAND         fax: +44 (0)782 713082