Version 1.1 of ais/ai-00364.txt

Unformatted version of ais/ai-00364.txt version 1.1
Other versions for file ais/ai-00364.txt

!standard 03.07(08/1)          03-12-04 AI95-00364/00
!class amendment 03-12-04
!status received 03-09-29
!priority Medium
!difficulty Hard
!subject Fixed-point multiple/divide
!summary
Those ^&**^$% access subtypes gotta go.
!problem
[Editor's note: this is not a full write-up.]
!proposal
Disallow the discriminant constraint on a general access type if the discriminants have defaults on the designated type, recheck in an instance and presume the worst in a generic body.
We must disallow constraints on all access types declared outside the package defining the private type (presuming the private view has no visible discriminants), allocating space for unconstrained objects in the heap even when constraints are given in the allocator for such an access type, and setting the 'Constrained attribute False when dereferencing values of such an access type.
If the access type is a general access type, then this "new" semantics for allocators should apply to access types declared inside the package as well, presuming the designated subtype is not constrained, since subtypes would be disallowed on the "inside" general access types as well. Furthermore, there would need to be rules disallowing a 'Access that delivers a value of such a type being applied to a constrained variable (3.7.2(27)), and disallowing conversion from some other access type that had constrained designated objects (4.6(16)). Both 3.7.2(27) and 4.6(16) would then say "discriminated and indefinite" rather than "discriminated and unconstrained."
!wording
!discussion
!example
--!corrigendum
!ACATS test
ACATS test(s) should be constructed to check these changes.
!appendix

From: Tucker Taft
Sent: Monday, September 29, 2003 10:53 PM

I indicated I had a solution for the ada 95/ada 83
incompatibility relating to fixed-point multiply/divide,
where user-defined multiply are not usable because
of the "pervasive" visibility of the universal-fixed
multiply/divide operations.

After taking a shot at defining the universal-access
equality operators in standard, it became obvious
that there is a simple fix for the universal-fixed
incompatibility.  Just have a name-resolution rule
which forbids use of the universal-fixed operations
if both operand types have at least one primitive user-defined multiply
operator, in the case of the univ-fixed multiply op,
or both have at least one primitive user-defined divide operator in
the case of the univ-fixed divide op.

This doesn't have any beaujolais effects, because it isn't
a preference rule.  Just certain fixed-point type combinations
can't be used with the universal-fixed multiply/divide
operators, based strictly on whether they both have their
own primitive multiply/divide operators.

[I phrased the suggested rule as requiring "both" to have
a user-defined primitive operator, but it could be
phrased as "either." ]

By the way, this isn't totally hypothetical.  At one
point we definitely dealt with a customer who was trying
to figure out how to get their old Ada 83 fixed-point code
to work, and the answer was not pretty.  Basically they
had to use non-operator functions like "mul" and "div",
and live with the fact that they couldn't prevent misuse
of the predefined univ-fixed operators.

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

From: Robert Dewar
Sent: Monday, September 29, 2003 10:55 PM

We have run into similar situations. I like this fix. I think it is
worth while. In fact I would suggest allowing Ada 95 compilers to do
this right away, why not?

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

From: Robert I. Eachus
Sent: Tuesday, September 30, 2003  3:45 PM


Tucker said:

> This doesn't have any beaujolais effects, because it isn't
> a preference rule.  Just certain fixed-point type combinations
> can't be used with the universal-fixed multiply/divide
> operators, based strictly on whether they both have their
> own primitive multiply/divide operators.

First let me say that this problem is MUCH more serious than potential
beaujolais effects.  A good solution now should be preferred to continuing to
look for a perfect solution.  There may be a clean and easy to implement
solution without beaujolais effects.  If so great.  But a preference rule NOW
would be great too.

> [I phrased the suggested rule as requiring "both" to have
> a user-defined primitive operator, but it could be
> phrased as "either." ]

There are three potential fixed-point types involved, two operands and a
result.  I think Tucker is talking about when the two operands both have user
defined multiply or divide operations.  I don't particularly care what the
exact rule is though, as long as you get it defined for all cases.

> By the way, this isn't totally hypothetical.  At one
> point we definitely dealt with a customer who was trying
> to figure out how to get their old Ada 83 fixed-point code
> to work, and the answer was not pretty.  Basically they
> had to use non-operator functions like "mul" and "div",
> and live with the fact that they couldn't prevent misuse
> of the predefined univ-fixed operators.

I have/had some fielded Ada 83 code on one project where this one issue was
enough to cause the project to stay with a "baselined" Ada 83 compiler.  I
don't know that the particular package ever got rewritten for Ada 95, but
distance times sine returning distance, and (apparent) speed divided by cosine
to give ground speed were two examples of where it was used in the code.

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

Questions? Ask the ACAA Technical Agent