comp.lang.ada
 help / color / mirror / Atom feed
* Statically matching constraints
@ 2007-02-03  0:26 Adam Beneschan
  2007-02-03 14:41 ` Ludovic Brenta
  2007-02-06  1:13 ` Randy Brukardt
  0 siblings, 2 replies; 4+ messages in thread
From: Adam Beneschan @ 2007-02-03  0:26 UTC (permalink / raw)


I'm having a bit of trouble understanding the "both are nonstatic and
result from..." clause of 4.9.1(1.3/2).  According to 7.3(13), if you
have a discriminant on the ancestor subtype of a private extension,
the full definition must impose a statically matching constraint,
which takes you to 4.9.1.  With this in mind, which of these examples
is legal?

  package Pak1 is
       X : Integer := 3;
       type T1 (A : Integer) is tagged null record;
       type T2 is new T1(X) with private;
  private
       type T2 is new T1(X) with null record;
  end Pak1;

  package Pak2 is
       X : constant Integer := Some_Other_Package.Some_Function(100);
       type T1 (A : Integer) is tagged null record;
       type T2 is new T1(X) with private;
  private
       type T2 is new T1(X) with null record;
  end Pak2;

  package Pak3 is
       X : Integer := 3;
       type Sub is Integer range 1..X;
       type T1 (A : Integer) is tagged null record;
       type T2 is new T1(Sub'Last) with private;
  private
       type T2 is new T1(Sub'Last) with null record;
  end Pak3;

My reading is that Pak1 and Pak2 are illegal but Pak3 seems to be
legal.  The constraints are all nonstatic (the fact that X is a
constant in Pak2 isn't enough to make it static), but it seems to me
that Pak3 is the only one where the constraint results from something
mentioned in 4.9.1(1.3/2), since it seems to result from "the same
evaluation of a range of a discrete_subtype_definition", while in Pak1
and Pak2 the constraints result from evaluations of a variable or
constant, respectively.  But it's a little confusing to me because I'm
not clear on just what "result from" is supposed to mean, and the AARM
is no help.

Is my interpretation correct?

(And yes, I already know you can make this legal by eliminating the
discriminant from the private extension declaration.  That isn't my
question.)

                       -- thanks, Adam




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Statically matching constraints
  2007-02-03  0:26 Statically matching constraints Adam Beneschan
@ 2007-02-03 14:41 ` Ludovic Brenta
  2007-02-06  1:13 ` Randy Brukardt
  1 sibling, 0 replies; 4+ messages in thread
From: Ludovic Brenta @ 2007-02-03 14:41 UTC (permalink / raw)


Adam Beneschan writes:
>   package Pak3 is
>        X : Integer := 3;
>        type Sub is Integer range 1..X;

Surely you meant

         subtype Sub is Integer range 1 .. X;

>        type T1 (A : Integer) is tagged null record;
>        type T2 is new T1(Sub'Last) with private;
>   private
>        type T2 is new T1(Sub'Last) with null record;
>   end Pak3;
>
> My reading is that Pak1 and Pak2 are illegal but Pak3 seems to be
> legal.  The constraints are all nonstatic (the fact that X is a
> constant in Pak2 isn't enough to make it static),

X would be static, I think, if Some_Function were a static function,
since you are already passing a static parameter to Some_Function.
That would make Pak2 legal.

> but it seems to me
> that Pak3 is the only one where the constraint results from something
> mentioned in 4.9.1(1.3/2), since it seems to result from "the same
> evaluation of a range of a discrete_subtype_definition", while in Pak1
> and Pak2 the constraints result from evaluations of a variable or
> constant, respectively.  But it's a little confusing to me because I'm
> not clear on just what "result from" is supposed to mean, and the AARM
> is no help.
>
> Is my interpretation correct?
>
> (And yes, I already know you can make this legal by eliminating the
> discriminant from the private extension declaration.  That isn't my
> question.)

How about

       type T1 (A : Integer) is tagged null record;
       type T2 is new T1(A : Integer) with private;
  private
       type T2 is new T1(A => X) with null record;

Would that be legal?

Sorry I can't be of more help, asking more questions instead of
answering :) but FWIW I agree with your interpretation of
4.9.1(1.3/2).

-- 
Ludovic Brenta.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Statically matching constraints
  2007-02-03  0:26 Statically matching constraints Adam Beneschan
  2007-02-03 14:41 ` Ludovic Brenta
@ 2007-02-06  1:13 ` Randy Brukardt
  2007-02-06  2:27   ` Adam Beneschan
  1 sibling, 1 reply; 4+ messages in thread
From: Randy Brukardt @ 2007-02-06  1:13 UTC (permalink / raw)


"Adam Beneschan" <adam@irvine.com> wrote in message
news:1170462379.446684.247730@q2g2000cwa.googlegroups.com...
> I'm having a bit of trouble understanding the "both are nonstatic and
> result from..." clause of 4.9.1(1.3/2).  According to 7.3(13), if you
> have a discriminant on the ancestor subtype of a private extension,
> the full definition must impose a statically matching constraint,
> which takes you to 4.9.1.

This rule hasn't changed since Ada 95 (other than to make it into a list of
bullets in order to add a missing case for formal types).

...
> My reading is that Pak1 and Pak2 are illegal but Pak3 seems to be
> legal.  The constraints are all nonstatic (the fact that X is a
> constant in Pak2 isn't enough to make it static), but it seems to me
> that Pak3 is the only one where the constraint results from something
> mentioned in 4.9.1(1.3/2), since it seems to result from "the same
> evaluation of a range of a discrete_subtype_definition", while in Pak1
> and Pak2 the constraints result from evaluations of a variable or
> constant, respectively.  But it's a little confusing to me because I'm
> not clear on just what "result from" is supposed to mean, and the AARM
> is no help.
>
> Is my interpretation correct?

I don't think so. 7.3(13) is talking about the constraint of T in
T(Sub'Last). Since Sub is not static, Sub'Last isn't static either, so the
constraint of T(Sub'Last) isn't static. Thus the two copies of T(Sub'Last)
don't match.

The notes in AARM 7.3(13.e-g) give a clue to the answer to your question.
The AARM notes point out that you can't give a discriminant constraint in
the partial view if it is a discriminant. The same holds true for any
non-static value, because, by definition the two constraints are different
and non-static: thus they don't match.

(At least, that is how I interpret it.)

                            Randy.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Statically matching constraints
  2007-02-06  1:13 ` Randy Brukardt
@ 2007-02-06  2:27   ` Adam Beneschan
  0 siblings, 0 replies; 4+ messages in thread
From: Adam Beneschan @ 2007-02-06  2:27 UTC (permalink / raw)


On Feb 5, 5:13 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> "Adam Beneschan" <a...@irvine.com> wrote in message
>
> news:1170462379.446684.247730@q2g2000cwa.googlegroups.com...
>
> > I'm having a bit of trouble understanding the "both are nonstatic and
> > result from..." clause of 4.9.1(1.3/2).  According to 7.3(13), if you
> > have a discriminant on the ancestor subtype of a private extension,
> > the full definition must impose a statically matching constraint,
> > which takes you to 4.9.1.
>
> This rule hasn't changed since Ada 95 (other than to make it into a list of
> bullets in order to add a missing case for formal types).
>
> ...
>
> > My reading is that Pak1 and Pak2 are illegal but Pak3 seems to be
> > legal.  The constraints are all nonstatic (the fact that X is a
> > constant in Pak2 isn't enough to make it static), but it seems to me
> > that Pak3 is the only one where the constraint results from something
> > mentioned in 4.9.1(1.3/2), since it seems to result from "the same
> > evaluation of a range of a discrete_subtype_definition", while in Pak1
> > and Pak2 the constraints result from evaluations of a variable or
> > constant, respectively.  But it's a little confusing to me because I'm
> > not clear on just what "result from" is supposed to mean, and the AARM
> > is no help.
>
> > Is my interpretation correct?
>
> I don't think so. 7.3(13) is talking about the constraint of T in
> T(Sub'Last). Since Sub is not static, Sub'Last isn't static either, so the
> constraint of T(Sub'Last) isn't static.

But 4.9.1(1.3/2) seems to make it clear that two constraints can be
statically matching even if they're nonstatic, under certain
conditions.  (That seems to be the whole purpose of this paragraph:
static constraints are covered in the previous paragraph.) The
question is exactly what those conditions are, and the wording isn't
clear enough to me, for me to figure out whether that applies in the
Sub'Last example---that's the main point of my question.  7.3(13)
doesn't require that the two constraints involved be static---only
that they be staticlaly matching.

                                   -- Adam








^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-02-06  2:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-03  0:26 Statically matching constraints Adam Beneschan
2007-02-03 14:41 ` Ludovic Brenta
2007-02-06  1:13 ` Randy Brukardt
2007-02-06  2:27   ` Adam Beneschan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox