Subtypes boundaries

Subtypes boundaries

[Nobody]

Hi All,

I am new to Ada and found the following declaration in my text book:

type ASTERIX is range -5_000..+10_000;
subtype IDEFIX is range 1..20_000;

How can it be that the subtype IDEFIX can exceed the boundaries (20_000 
compared to 10_000) of the superordinated type ASTERIX? If it is a 
subtype its boundaries should be within the boundaries of the type it is 
derived from. Did I get something wrong?

Regards

Nobody

Re: Subtypes boundaries

[Jeffrey R. Carter]

Nobody wrote:
> 
> I am new to Ada and found the following declaration in my text book:
> 
> type ASTERIX is range -5_000..+10_000;
> subtype IDEFIX is range 1..20_000;

Which text book are you using? All caps for identifiers has not been commonly 
used for 15 years or more.

If you really found that in your text, you should get another text. The 
declaration of Idefix is invalid, as it does not give the parent subtype. A 
valid subtype declaration is

subtype Positive is Integer range 1 .. Integer'Last;

You are correct that the range of a subtype cannot exceed that of its parent.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Subtypes boundaries

[Nobody]

On Mon, 14 Jun 2010 13:36:13 -0700 Jeffrey R. Carter wrote:

Hi Jeff,

thanks for your answer.

> Which text book are you using? All caps for identifiers has not been
> commonly used for 15 years or more.

Can you give me direction where I can find documents about the current 
common use of Ada as you stated above?

Best regards

Nobody
 

Re: Subtypes boundaries

[Nasser M. Abbasi]

On 6/17/2010 11:54 AM, Nobody wrote:
> On Mon, 14 Jun 2010 13:36:13 -0700 Jeffrey R. Carter wrote:
>
> Hi Jeff,
>
> thanks for your answer.
>
>> Which text book are you using? All caps for identifiers has not been
>> commonly used for 15 years or more.
>
> Can you give me direction where I can find documents about the current
> common use of Ada as you stated above?
>
> Best regards
>
> Nobody
>
>
>

gnat has a tool to check for styling:

http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Style-Checking.html

"The -gnatyx switch causes the compiler to enforce specified style rules"

--Nasser

Re: Subtypes boundaries

[Jeffrey R. Carter]

Nobody wrote:
> 
> Can you give me direction where I can find documents about the current 
> common use of Ada as you stated above?

You can look at the capitalization used in the ARM:

http://www.adaic.org/standards/05rm/html/RM-TOC.html

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: Subtypes boundaries

[Ludovic Brenta]

On comp.lang.ada:
> On Mon, 14 Jun 2010 13:36:13 -0700 Jeffrey R. Carter wrote:
>
> Hi Jeff,
>
> thanks for your answer.
>
>> Which text book are you using? All caps for identifiers has not been
>> commonly used for 15 years or more.
>
> Can you give me direction where I can find documents about the current 
> common use of Ada as you stated above?

The Ada Quality and Style Guide:

http://www.adaic.org/docs/95style/html/sec_3/3-1-3.html

-- 
Ludovic Brenta.

Re: Subtypes boundaries

[Nobody]

On Mon, 14 Jun 2010 20:25:48 +0000 Nobody wrote:

I am sorry, I have to correct the statements.

type ASTERIX is range -5_000..+10_000;
subtype IDEFIX is ASTERIX range 1..20_000;

Regards

Nobody

Re: Subtypes boundaries

[Gautier write-only]

> type ASTERIX is range -5_000..+10_000;
> subtype IDEFIX is ASTERIX range 1..20_000;

If it is what is in your text book, then it is a mistake - at least
from a didactic perspective...
To my surprise, it looks legal Ada.
One (old) compiler compiles without a complaint;
another one (recent) compiles but issues this warning:

obelix.adb:3:38: warning: static value out of range of type "ASTERIX"
defined at line 2
obelix.adb:3:38: warning: "Constraint_Error" will be raised at run
time

And keeps its promise at run-time:

Execution terminated by unhandled exception
Exception name: CONSTRAINT_ERROR
Message: obelix.adb:3 range check failed

G.

Re: Subtypes boundaries

[Yannick Duchêne (Hibou57)]

Le Mon, 14 Jun 2010 23:01:17 +0200, Gautier write-only  
<gautier_niouzes@hotmail.com> a écrit:
> To my surprise, it looks legal Ada.
The base type of IDEFIX is ASTERIX, by definition.

[ARM 2005 3.5(5)] just says:
> For a subtype_indication containing a range_constraint, either directly 
> or as part of some other scalar_constraint, the type of the range shall
> resolve to that of the type determined by the subtype_mark of the
> subtype_indication.

Nowhere in 3.5 I could find something explicitly stating when the error  
must be detected (compile time or runtime).

If the ranges was defined using non-literal, like values of type ASTERIX,  
and if these was variables, then there would be no other way except a  
runtime detection of an error.

What disturbed me, is that a literal here, match an ASTERIX while it is  
statically out-of range ?

Needs investigation in the RM (or may be the reference lacks something  
here ?). What is the RM part involved here ?

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Subtypes boundaries

[Peter C. Chapin]

Yannick Duchêne (Hibou57) wrote:

> What disturbed me, is that a literal here, match an ASTERIX while it is  
> statically out-of range ?

I think that's accepted because the literal is a Universal Integer.

Peter

Re: Subtypes boundaries

[Adam Beneschan]

On Jun 14, 5:01 pm, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> Yannick Duchêne (Hibou57) wrote:
> > What disturbed me, is that a literal here, match an ASTERIX while it is  
> > statically out-of range ?
>
> I think that's accepted because the literal is a Universal Integer.

No, that's not the reason.  In fact, with one compiler, the above code
gives me a warning, but if I change the out-of-range upper bound by
sticking another zero on it:

subtype IDEFIX is ASTERIX range 1..200_000;

then it gives me an error and rejects the program---as I expected.

Here's the reason: The only error that has to be caught at compile
time is when the value is out of the *base* *range* of the expected
type (see 4.9(35)).  The base range for ASTERIX is not -5000 .. 10000;
it's some other range selected by the compiler, and I think in this
case this compiler probably selects
-32768 .. 32767.

I can understand why this all might be confusing to a newcomer.  I'm
not exactly sure why the language rules were done this way.  But I do
know that good practice often means writing programs in such a way
that you should be able to change a program's behavior by changing a
constant without having to go through the whole rest of the code
figuring out what else might have to be changed (sorry, I forgot the
term for that), and that means that sometimes a program will have IF
statements where the condition will always be false (or true), and you
don't want to have language rules that force a program to be rejected
if it contains a statement that is statically known to fail inside a
block of code that will never be executed.  Maybe that was the
motivation.

                               -- Adam

Re: Subtypes boundaries

[Nobody]

On Tue, 15 Jun 2010 01:31:47 +0200 Yannick Duchêne (Hibou57) wrote:

> [ARM 2005 3.5(5)] just says:
>> For a subtype_indication containing a range_constraint, either directly
>> or as part of some other scalar_constraint, the type of the range shall
>> resolve to that of the type determined by the subtype_mark of the
>> subtype_indication.
> 
The annotated ARM says:

3.5 Scalar Types, 8.a
Ramification: Only range_constraints (explicit or implicit) impose 
conditions on the values of a scalar subtype. The other 
scalar_constraints, digit_constraints and delta_constraints impose 
conditions on the subtype denoted by the subtype_mark in a 
subtype_indication, but don't impose a condition on the values of the 
subtype being defined. Therefore, a scalar subtype is not called 
constrained if all that applies to it is a digits_constraint. Decimal 
subtypes are subtle, because a digits_constraint without a 
range_constraint nevertheless includes an implicit range_constraint. 

What I understand is that a subtype shall in maximum contain all values 
of the subtype indicator, i.e. the superordinated type. Therefore the 
definition

type ASTERIX range +5_000..10_000;
subtype IDEFIX is ASTERIX range 1..20_000;

should in ANY case cause a compile time error!!!

At least I would expect this behaviour.

Regards

Nobody

Re: Subtypes boundaries

[Adam Beneschan]

On Jun 14, 6:05 pm, Nobody <nob...@nowhere.org> wrote:
> On Tue, 15 Jun 2010 01:31:47 +0200 Yannick Duchêne (Hibou57) wrote:
>
> > [ARM 2005 3.5(5)] just says:
> >> For a subtype_indication containing a range_constraint, either directly
> >> or as part of some other scalar_constraint, the type of the range shall
> >> resolve to that of the type determined by the subtype_mark of the
> >> subtype_indication.
>
> The annotated ARM says:
>
> 3.5 Scalar Types, 8.a
> Ramification: Only range_constraints (explicit or implicit) impose
> conditions on the values of a scalar subtype. The other
> scalar_constraints, digit_constraints and delta_constraints impose
> conditions on the subtype denoted by the subtype_mark in a
> subtype_indication, but don't impose a condition on the values of the
> subtype being defined. Therefore, a scalar subtype is not called
> constrained if all that applies to it is a digits_constraint. Decimal
> subtypes are subtle, because a digits_constraint without a
> range_constraint nevertheless includes an implicit range_constraint.
>
> What I understand is that a subtype shall in maximum contain all values
> of the subtype indicator, i.e. the superordinated type. Therefore the
> definition
>
> type ASTERIX range +5_000..10_000;
> subtype IDEFIX is ASTERIX range 1..20_000;
>
> should in ANY case cause a compile time error!!!

3.5(8), which you're reading, is in a "Dynamic Semantics" section.
Whatever you see there explains how the program will behave at run
time.  Nothing in a Dynamic Semantics section should ever affect
whether you get an error at compile time or not, I think.  The rules
that cause compile-time errors are in "Legality Rules" sections, and
perhaps in "Static Semantics".

As for why this would cause an error at run time but not at compile
time, I've tried to explain already why it might be a good idea to
have the language rules this way.  What this means is that if your
compiler tells you that something you wrote will raise an exception at
run time, take it seriously, as seriously as you'd take an actual
error.

                                   -- Adam