Version 1.1 of acs/ac-00203.txt

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

!standard 12.3(5)          10-10-21 AC95-00203/01
!class confirmation 10-10-21
!status received no action 10-10-21
!status received 10-05-01
!subject Discriminant proposals for future Ada standards
!summary
!appendix

From: Pascal Pignard
Sent: Saturday, May 1, 2010  4:49 AM

Hello.

I'm new to this list and I wasn't able to find web page list archive of
Ada-Comment. Thus don't hesitate to give me some feedback.

I want to write the following Ada code:
type TÉléments is array (Natural range <>) of Integer; type Typ (Max : Natural := 256) is  record
	Éléments : TÉléments(0..Max-1):=(others=>0); -- error Max-1 not allowed in Ada 2005
	end record;
X : Typ(20);

You'll easily see that it's sound like a direct translation of C syntax, in fact
it's to translate Java code in Ada. Whatever, could it be possible to add some
more flexible rules in discriminant usage?

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

From: Randy Brukardt
Sent: Tuesday, May 4, 2010  1:25 AM

> I'm new to this list and I wasn't able to find web page list archive
> of Ada-Comment.

There isn't one per-se. You can get digests from the mailing list manager. But
it's easier to just search the filed AIs and ACs, because almost all of the mail
ends up in one of them. (I say "almost" because stuff not related to Ada goes
into the trash.) So, I suggest using one of the search possibilities on
www.ada-auth.org.

> Thus don't hesitate to give me some feedback.
>
> I want to write the following Ada code:
> type TÉléments is array (Natural range <>) of Integer; type Typ (Max :
> Natural := 256) is  record
> 	Éléments : TÉléments(0..Max-1):=(others=>0); -- error
> Max-1 not allowed in Ada 2005
> 	end record;
> X : Typ(20);
>
> You'll easily see that it's sound like a direct translation of C
> syntax, in fact it's to translate Java code in Ada.
> Whatever, could it be possible to add some more flexible rules in
> discriminant usage?

This has been discussed repeatedly in the last 20 years; for Ada 95 in
particular. The most recent discussion was in AC-00080.TXT (see
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/acs/ac-00080.txt), which demonstrates
that making the expression completely general would be counterproductive.

For most implementations, the effect would be the same as for an unconstrained
object. That means that in your example, Natural'Last*Integer'Size bits would be
allocated for Elements -- that's not likely to be what you want.

It probably would be possible to allow some very restricted expressions in this
context (such as your "Max-1"), but that isn't very much in the spirit of Ada.
Moreover, it would is likely to be a substantial implementation effort to check
the rules (whatever they are), a substantial effort to write the rules, and most
likely they would be different than the set that was optimal for a particular
implementation. And the result is unlikely to make anyone very happy (well,
perhaps other than you!).

Anyway, the enhancement list for Ada 2012 is already set, so it is likely that
it will be quite a while before this is seriously considered.

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

From: Pascal Pignard
Sent: Friday, May 7, 2010  3:08 PM

Thanks Randy for your kind answer.

I"m just surprised that Ada 2012 list is already closed, mid-2010.
But I'm glad to know that my point has been already discussed ;-)

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

From: Randy Brukardt
Sent: Saturday, May 8, 2010  12:13 AM

It takes more than 9 months (usually more than a year) to get a completed
standard actually approved and published. It also takes more than a year of
polishing, looking at feature interactions, careful editorial reviews, etc.
before we even start formal approval. (Think how much time debugging takes
compared to writing a program; it's the same basic problem.) So to get it
published by the end of 2012, it needs to be reaching the final stages now. (And
actually, the plan is to have it finished in the first half of 2012, so there is
even less time.)

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

From: Bob Duff
Sent: Saturday, May 8, 2010  7:25 AM

> (Think how much time debugging
> takes compared to writing a program; it's the same basic problem.)

Besides, the RM is not written in a strongly typed language.

;-)

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

From: Yannick Moy
Sent: Saturday, May 8, 2010  7:03 PM

I have come across this restriction several times, as in the following case:

   type Part (Max_Players : Positive) is record
      Inter       : Interpreter;  --  Interpreter for this part
      Instr       : Instrument;   --  Instrument for this part
      Num_Players : Positive range 1 .. Max_Players;  --  Number of players
      Pos         : Positions (1 .. Max_Players);  --  Position of each player
   end record;

GNAT complains that:

conductor.ads:10:41: discriminant cannot constrain scalar type

How hard is this restriction? Will it be lifted in some next version of the
standard? Or are there very good reasons not to allow the above code?

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

From: Bob Duff
Sent: Friday, May 14, 2010  7:56 AM

> How hard is this restriction? Will it be lifted in some next version
> of the standard?

As far as I know, there are no plans to remove this restriction.

>... Or are there very good reasons not to allow the above code?

No, there is no good reason for the restriction, other than "that's the way it
always was, and there's some cost to change it".  It's one of those things where
the cost/benefit ratio is near-zero divided by near-zero, so it's hard to
estimate.

See 3.8(12,12.c).

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

From: John Barnes
Sent: Monday, May 17, 2010  2:20 AM

This has annoyed me for years. See Programming in Ada 2005 page 402.

But nobody seems to care.

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

From: Yannick Moy
Sent: Monday, May 17, 2010  4:14 PM

>>>    type Part (Max_Players : Positive) is record
>>>       Inter       : Interpreter;  --  Interpreter for this part
>>>       Instr       : Instrument;   --  Instrument for this part
>>>       Num_Players : Positive range 1 .. Max_Players;  --  Number of
>>> players
>>>       Pos         : Positions (1 .. Max_Players);  --  Position of
>>> each player
>>>    end record;

Would be logic to allow, as this can already constraints valid indexes on Pos.

>> No, there is no good reason for the restriction, other than "that's
>> the way it always was, and there's some cost to change it".  It's one
>> of those things where the cost/benefit ratio is near-zero divided by
>> near-zero, so it's hard to estimate.

Where would the cost belong ? In existing implementations or in the language
definition ?

There may be a cost also, for applications, to not be able to express this
constraint. This is a cost to be weighed too.

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

From: Bob Duff
Sent: Monday, May 17, 2010  5:19 PM

> Would be logic to allow, as this can already constraints valid indexes
> on Pos.

Right.  I don't think anyone disagrees with that.

> Where would the cost belong ? In existing implementations or in the
> language definition ?

Implementation, mostly.  The cost in the language definition is (probably) just
removing the rule.  Both are small, neither is zero.

> There may be a cost also, for applications, to not be able to express
> this constraint. This is a cost to be weighed too.

That's the "benefit" (to removing the restriction).  ;-)

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

From: Yannick Moy
Sent: Tuesday, May 18, 2010  7:58 PM

>> conductor.ads:10:41: discriminant cannot constrain scalar type

> No, there is no good reason for the restriction, other than "that's
> the way it always was, and there's some cost to change it".  It's one
> of those things where the cost/benefit ratio is near-zero divided by
> near-zero, so it's hard to estimate.

Great, if the cost is near-zero, why not allow it?

I don't see the benefit as near-zero... after all, it is a kind of type
invariant, for which the ARG is considering both subtype predicates
(AI05-0153-1) and type invariant (AI05-0146-1).

So that you could express it here as a subtype predicate:

   type Part (Max_Players : Positive) is record
      Inter       : Interpreter;  --  Interpreter for this part
      Instr       : Instrument;   --  Instrument for this part
      Num_Players : Positive;  --  Number of players
      Pos         : Positions (1 .. Max_Players);  --  Position of each player
   end record;

   subtype Sub_Part is Part
    with Predicate => Part.Num_Players in 1 .. Max_Players;

But this is kind of clumsy compared to simply expressing a constraint based on
the discriminant's value.

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

From: Randy Brukardt
Sent: Tuesday, May 18, 2010  8:25 PM

> It's one
> of those things where the cost/benefit ratio is near-zero divided by
> near-zero, so it's hard to estimate.

The cost to change it for Janus/Ada would not be "near-zero", as it would
require a new kind of subtype (index constraint depending on a discriminant and
discriminant constraint depending on a discriminant being special kinds of
subtypes now). That would affect a lot of places in our compiler (many case
statements that would need a new kind for completeness, at least). It wouldn't
be particularly hard, but I'd expect it to be fairly time-consuming. (That's
assuming a minimal non-optimizing implementation, which would seem appropriate
for a feature with a benefit of "near-zero").

I don't think I've ever really run into this particular problem; the lack of
expressions in index constraints has bit me several times, but see the most
recent thread on that topic for why eliminating that restriction probably
wouldn't have the desired effect.

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


Questions? Ask the ACAA Technical Agent