Version 1.1 of acs/ac-00051.txt

Unformatted version of acs/ac-00051.txt version 1.1
Other versions for file acs/ac-00051.txt

!standard A.5.2(00)          03-01-23 AC95-00051/01
!class amendment 03-01-23
!status received no action 02-11-26
!subject Random number packages should be pure
!summary
!appendix

From: Matthew Heaney
Sent: Tuesday, November 19, 2002 11:09 AM

> I don't like it because:
>...
>     - (Most importantly) The spec of function Random is a lie!

Again, it depends on what model you're using.  Not all state changes need be
advertised in the public part of the spec, because in the "logical" view of the
type there is no state change.

The problem is that parameter modes ("in" vs. "inout") in Ada conflate these
two views ("logical" vs. "physical") of the abstraction.  This is not unlike
the problem with overriding operators for a type; it would be better if the
public and private views of a type were in separate namespaces.  For example,
if I do this:

   type T is private;

   function "+" (L, R : T) return T;

private

   type T is new Integer;

The problem here is that I've lost access to the predefined "+" for type T.
This often trips new Ada programmers, who will try to implement the overriden
"+" operator using the predefined operator, and end up with infinite recursion
instead.

The real issue is that there should be different ways to communicate
information to the compiler vs communicate information to the programmer using
the abstraction.  You, Bob Duff, want a random number generator to announce its
state change, but that is the compiler-writer in you speaking.  For a
programmer (like me) who needs to use a random number generator, I don't really
care whether the function is "in" or "inout" because the syntax is the same.

(Actually, this was Jean's motivation for *not* allowing the parameter-passing
mode to be used in overload resolution, because it's not obvious at the point
of call which operation is being invoked.  This is explained in the Ada83
Rationale.)

> Apparently, the author of the GNAT version didn't know about this trick.
> Apparently, the MRT didn't know about it either, when the RM was
> written, because the AARM suggests a heap-based implementation.  In
> fact, that AARM comment was wrong; the version-with-corrigendum fixes
> it (to a different heap-based implementation).

I hope the Rosen Trick is in there somewhere.  I consider it superior to your
technique of using assignment to a named access type.

I still maintain that the language should give implementors freedom to declare
the random number generator packages as Pure.  (I would like it even better if
the RM required Pure.)

****************************************************************

From: Robert A. Duff
Sent: Tuesday, November 19, 2002 11:30 AM

No, I don't think so.  Random number generation is *conceptually*
impure, because each time you call Random, you want to get a different
answer.  This is different from a Sin function that always returns the
same value (but does memo-izing -- it has a secret implementation-level
side effect that is not visible to clients).  If you complain that Sin
can't have pragma Pure (which Robert has, loudly ;-)), I have some
sympathy.

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 19, 2002 12:51 PM

Yes, of course that's true. However, as we all know :-(
Pure means many things in Ada.

One thing it means is that if you are impure you may not keep company
with the pure.

It is *entirely* reasonable to have a pure package that with's the random
number package.

There is however a canonical and in practice portable way of getting around
this, which is to use a wrapper that uses pragma Import/Export (Ada, ...)

Yes, this is hyper-ugly, but it is all under the covers, and you can produce
a nice clear pure interface (well all except for the lack of IN OUT :-)

****************************************************************

From: Matthew Heaney
Sent: Tuesday, November 19, 2002 12:50 PM

So what is your verdict on whether it is *possible* for the random number
packages to have Pure categorization?

****************************************************************

From: Robert A. Duff
Sent: Tuesday, November 19, 2002  6:06 PM

I can't see how it makes any sense to do so.
I don't see why you would want to.

****************************************************************

From: Matthew Heaney
Sent: Tuesday, November 19, 2002  6:12 PM

So that a pure package can with the random number generator package, of course!

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 19, 2002  6:22 PM

No idea what this is asking, obviously you can design a random number
package to be pure. If you are asking if *the* defined package in Ada
can have Pure categorization, the answer is no, since there is no such
pragma Pure in the RM.

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 19, 2002  6:35 PM

> I can't see how it makes any sense to do so.

Well it is not quite clear what PURE means if you allow IN OUT parameters
for functions, but it can certainly be defined in a way that this makes sense.

> I don't see why you would want to.

I answered this earlier, and I must say I find Bob's comment here very
strange. It is a huge problem in Ada that pure units cannot WITH impure
units. It makes absolutely perfect sense to have a pure unit that uses
random numbers!

****************************************************************

From: Robert A. Duff
Sent: Tuesday, November 19, 2002  6:44 PM

But the same could be said of *any* package.  I mean, why not make
Text_IO pure?  It's useful in pure packages (for debugging).

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 19, 2002  6:53 PM

Here is the preamble to the package GNAT.IO:

> --  A simple preelaborable subset of Text_IO capabilities
>
> --  A simple text I/O package that can be used for simple I/O functions in
> --  user programs as required. This package is also preelaborated, unlike
> --  Text_IO, and can thus be with'ed by preelaborated library units.

Well not quite Pure, but the same principle ... in practice we very rarely
write pure units, because the restrictions are pretty fierce, but it is
indeed very common to make units preelaborable, and not being able to use
Text_IO from preelaborable packages is a fierce limitation.

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 19, 2002  6:58 PM

Note also that we have in GNAT pragma Pure_Function, so we can get the
advantages of making functions pure without the burden of making the
whole package Pure.

****************************************************************

From: Matthew Heaney
Sent: Tuesday, November 19, 2002  7:10 PM

> > So what is your verdict on whether it is *possible* for the random
> > number packages to have Pure categorization?
>
> No idea what this is asking, obviously you can design a random number
> package to be pure. If you are asking if *the* defined package in Ada
> can have Pure categorization, the answer is no, since there is no such
> pragma Pure in the RM.

I don't know how to interpret this answer.

In an earlier message, I presented an implementation of the random number
package, in which the package had Pure categorization, and the type was
implemented sans access types, using the Rosen Trick.

My question is, Is the implementation I provided a correct Ada program?  Or
does the language not define what the behavior is?

I ask because it compiles fine.  But now you're telling me that there is "no
such Pure in the RM."  It seems to me that if it compiles, then there certainly
*is* such a Pure.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 20, 2002  2:36 PM

> The "defining" semantics for a pure function
> is that if you give it the "same" parameters,
> you get back the same result.  This is patently
> false for a random number generator, so it makes
> no sense to make "random" itself pure.

Once again, random can perfectly well be defined as pure if one of the
arguments is the current state of the generator.

****************************************************************


Questions? Ask the ACAA Technical Agent