Ada.Strings.Bounded
in [ADA]
|
From: Adam Beneschan on 22 Apr 2008 16:15 On Apr 22, 11:47 am, Eric Hughes <eric....(a)gmail.com> wrote: > So now wait. When I declare > type X is range 0 .. 99 ; > does that mean that the value 100 is a value of type X? Yes. See 3.2.1(6). This declaration defines both a *type* X and its *first subtype* X. The type X includes all integers. The subtype X imposes a constraint of 0..99 on that type. When you declare Var : X; and then assign something into Var, the expression's value will be checked against the subrange 0..99, just as if you had said type Y is range 0..1_000_000_000; subtype YY is Y range 0..99; Var : YY; > And so now I have developed a Strong Opinion. This is a travesty. A > probably-irredeemable travesty. This is so completely counter- > intuitive that I have a hard time believing that competent people came > up with this way of writing the definition. It's unnecessary. There > are far better ways of defining this, and they don't break any > existing syntax. Back on April 15, in a different thread, you said "Make the formal standard normative, the human language expository", arguing that it would be OK for the formal standard to be inaccessible to human programmers. Now, in a case where the formal standard has been made a little bit complex in order to get the language to work they way they wanted it to work, then you complain about it not being intuitive. I don't think you can have it both ways. But I am going to complain bitterly about one thing: you are way out of line to insinuate that the people who came up with the standard are incompetent. WAY out of line. I know how much work the people who work on the standard put into it, and how much thought they put into making sure everything fits together and all the bases are covered while at the same time trying to make it reasonably readable. So even if you don't understand why the standard's authors defined something the way they did, you can assume there's a 99.9999% chance that there was a darn good reason why they did it that way. In this particular case, I think they saw a need to support static expressions with intermediate results that were larger than a machine integer, and the type/subtype definitions they came up with allowed them to accomplish this. -- Adam
From: Eric Hughes on 22 Apr 2008 18:55 On Apr 22, 1:41 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > I agree it's confusing. But "travesty" is too strong. In practise, > none of this matters much. Definitions matters if you wish to extend them. These definitions are not extensible. I still think it's a travesty. > Don't you want to be able to say "(Blah + 1) mod 99" without overflow > (where Blah is of subtype X)? I can do it without those definitions. Eric
From: christoph.grein on 23 Apr 2008 02:40 When you declare a type type T is range 1 .. 10; the name T denotes the first subtype of the anonymous type of T (the RM uses T in italics to denote this type, e.g. in 4.5.3, and this type has the infinite set of mathematical integers). Thus 11 *is* a value of the type of T (in sloppy language, the type T). The static named number S: constant := IntegerLast + IntegerLast; uses the "+" of Integer without overflow and converts the result to Universal_Integer. Therefore S: constant := IntegerLast + Long_IntegerLast; is not allowed because it mixes two different types, but T: constant := Long_IntegerLast; U: constant := S + T; is allowed, the "+" in the last expression being the one of root_integer.
From: christoph.grein on 23 Apr 2008 02:54 S: constant := IntegerLast + IntegerLast; -- "+" of Integer T: constant := Long_IntegerLast + 1; -- "+" of Long_Integer U: constant := S + T; -- "+" of root_integer V: constant := S + Long_IntegerLast; -- "+" of Long_Integer All of S, T, U, V are of type Universal_Integer.
From: Georg Bauhaus on 23 Apr 2008 06:42
Robert A Duff schrieb: >> And so now I have developed a Strong Opinion. This is a travesty. > > I agree it's confusing. But "travesty" is too strong. In practise, > none of this matters much. > > Don't you want to be able to say "(Blah + 1) mod 99" without overflow > (where Blah is of subtype X)? Hmm, less explicit and more lazy programming is attractive to many programmers, so just write expressions of a type that cannot be named, just in case of integers. But how about this: procedure Ex is type E is (A, B, C); X: E; begin X := E'pred(E'succ(C)); end Ex; In this case there is a static constraint error. Is this consistent with anything but the Ada LRM's exception for "integer convenience"? Without of course knowing why the choices were made the way they were made for the LRM, my conclusion is that many programmers still prefer high school ideas about numbers over the theory of computer numbers. Is it really inacceptable to write Larger_Type'(Blah + 1) mod 99; The expression doesn't hide a secret about its value range. |