Zoo question

Zoo question

[Ken Garlington]

Here's a little brain teaser we received recently. Assuming no typos or 
other obvious syntax errors, will the Fill procedure work in Ada 83?

package Zoo is

  type Animal_ID is range 1 .. 5; -- yes, an enumeration type might be
 	                                -- better, but it spoils the example!

  subtype Cage_ID is Positive range 1 .. 12;

  type Cage_Row is array (Cage_ID) of Animal_ID;

  -- Fill fills a row of cages with various animals, in sequential order
  -- with alternating animals
  procedure Fill ( Cages : in out Cage_Row );

end Zoo;

package body Zoo is

  procedure Fill ( Cages : in out Cage_Row ) is
    Next_Animal : Animal_ID := Animal_ID'First;
  begin -- Fill
    for Cage in Cages'Range loop

      Cages(Cage) := Next_Animal;

      Get_Next_Animal: begin -- look carefully at this code!
        Next_Animal := Animal_ID'Succ(Next_Animal);
      exception
        when others => Next_Animal := Animal_ID'First;
      end Get_Next_Animal;

    end loop;
  end Fill;

end Zoo;

Re: Zoo question

[Chris Morgan]

In article <320F16B6.6944@lmtas.lmco.com> Ken Garlington
<garlingtonke@lmtas.lmco.com> writes:


   Here's a little brain teaser we received recently. Assuming no typos or
   other obvious syntax errors, will the Fill procedure work in Ada 83?

I say yes because the sneaky begin starts a block with an exception
handler which catches the constraint_error of using 'succ on the last
enumerated value, so as far as the loop is concerned get_next_animal
does just that and it doesn't care about the exception.

However, I'm not confident as it doesn't seem to tease the brain much,
so go on, tell me where I'm missing some reason why the person who
wrote this got it wrong :-)

Chris Morgan
chris.morgan@baesema.co.uk

   package Zoo is
...

Re: Zoo question

[Ted Dennison]

Ken Garlington wrote:
> 
> Here's a little brain teaser we received recently. Assuming no typos or
> other obvious syntax errors, will the Fill procedure work in Ada 83?

OK. I'll bite. It looks like it would probably perform as advertised, with
no optimization set on the compiler. The following constraint check code -

> 
>       Get_Next_Animal: begin -- look carefully at this code!
>         Next_Animal := Animal_ID'Succ(Next_Animal);
>       exception
>         when others => Next_Animal := Animal_ID'First;
>       end Get_Next_Animal;

isn't guaranteed to work (assuming "work" means raise an execption within
this block when Animal_ID'Succ(Next_Animal) > Animal_ID'last).

Now, what did I miss? (it can't be that simple)

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Zoo question

[Ken Garlington]

Chris Morgan wrote:
> 
> In article <320F16B6.6944@lmtas.lmco.com> Ken Garlington
> <garlingtonke@lmtas.lmco.com> writes:
> 
>    Here's a little brain teaser we received recently. Assuming no typos or
>    other obvious syntax errors, will the Fill procedure work in Ada 83?
> 
> I say yes because the sneaky begin starts a block with an exception
> handler which catches the constraint_error of using 'succ on the last
> enumerated value, so as far as the loop is concerned get_next_animal
> does just that and it doesn't care about the exception.
> 

That certainly seems the intuitively obvious answer to me. Does anyone vote
for a row of cages filled with 1 .. Cages'Last?

-- 
LMTAS - "Our Brand Means Quality"

Re: Zoo question

[Ken Garlington]

Bob Gilbert wrote:
> 
> Right, so depending on the particular (Ada 83) compiler, the code may or
> may not produce the desired result, depending on whether the constraint
> check is performed within the begin block or not.

Under what circumstances would it be acceptable to not generate a range
check when assigning a value of 6 to an object declared with range 1 .. 5?

-- 
LMTAS - "Our Brand Means Quality"

Re: Zoo question

[Ted Dennison]

Ken Garlington wrote:
> 
> Ted Dennison wrote:
> >
> > isn't guaranteed to work (assuming "work" means raise an execption within
> > this block when Animal_ID'Succ(Next_Animal) > Animal_ID'last).
> 
> Now, the question is: Even though the call to Animal_ID'Succ(Animal_ID'Last)
> won't cause an exception (which I find very counter-intuitive, by the way),
> will an exception be raised on the line that contains that call?

Maybe, maybe not. I see three valid possibilities -

   1 - It raises an exception at the assignment. (This is what the code
       seems to be assuming)

   2 - No exception is ever raised (Constraint checking could be disabled 
       for any number of reasons).

   3 - A CONSTRAINT_ERROR is raised OUTSIDE the block, upon the next attempt
       to use the value of Animal_ID. (That's is what I meant by "within this
       block" above).

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Zoo question

[Paul Hussein]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:

>Here's a little brain teaser we received recently. Assuming no typos or 
>other obvious syntax errors, will the Fill procedure work in Ada 83?

>package Zoo is

>  type Animal_ID is range 1 .. 5; -- yes, an enumeration type might be
> 	                                -- better, but it spoils the example!

>  subtype Cage_ID is Positive range 1 .. 12;

>  type Cage_Row is array (Cage_ID) of Animal_ID;

>  -- Fill fills a row of cages with various animals, in sequential order
>  -- with alternating animals
>  procedure Fill ( Cages : in out Cage_Row );

>end Zoo;

>package body Zoo is

>  procedure Fill ( Cages : in out Cage_Row ) is
>    Next_Animal : Animal_ID := Animal_ID'First;
>  begin -- Fill
>    for Cage in Cages'Range loop

>      Cages(Cage) := Next_Animal;

>      Get_Next_Animal: begin -- look carefully at this code!
>        Next_Animal := Animal_ID'Succ(Next_Animal);
>      exception
>        when others => Next_Animal := Animal_ID'First;
>      end Get_Next_Animal;

>    end loop;
>  end Fill;

>end Zoo;
 I think it will 'work' also, but is not good example of ADA using
exceptions in that way.


I know youre going to come up with some more subtle problem.

Re: Zoo question

[Bob Gilbert]

In article <320F16B6.6944@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> Here's a little brain teaser we received recently. Assuming no typos or 
> other obvious syntax errors, will the Fill procedure work in Ada 83?
> 
> package Zoo is
> 
>   type Animal_ID is range 1 .. 5; -- yes, an enumeration type might be
>  	                                -- better, but it spoils the example!

{snip}

>       Get_Next_Animal: begin -- look carefully at this code!
>         Next_Animal := Animal_ID'Succ(Next_Animal);
>       exception
>         when others => Next_Animal := Animal_ID'First;
>       end Get_Next_Animal;

I assume that the tricky part is that the attribute 'Succ operates
on the base type of Animal_ID, which is of type integer, and does not
consider the constraint 1 .. 5 (although the attributes 'First and
'Last do).  That is if Next_Animal := 5, then Animal_ID'succ(Next_Animal)
would not raise an exception but would return the value 6.  However, 
I would expect an exception to occur when attempting to assign the 
result back to Next_Animal, so the code would probably produce the 
expected result (or perhaps not?).

Of course using an enumeration type for Animal_ID would avoid the
confusion.

Is this any different for Ada 95?

-Bob

Re: Zoo question

[Ted Dennison]

Bob Gilbert wrote:
> 
> In article <320F16B6.6944@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> > Here's a little brain teaser we received recently. Assuming no typos or
> > other obvious syntax errors, will the Fill procedure work in Ada 83?
> >
> > package Zoo is
> >
> >   type Animal_ID is range 1 .. 5; -- yes, an enumeration type might be
> 
> I assume that the tricky part is that the attribute 'Succ operates
> on the base type of Animal_ID, which is of type integer, and does not
> consider the constraint 1 .. 5 (although the attributes 'First and

This didn't sound right to me, so its LRM time...

3.5.4 -
the type declaration is equivalent to -

   type integer_type is new predefined_integer_type;
   subtype Animal_ID is integer_type range 1..5;

where integer_type is an ananoymous base type, snd predefined_integer_type
can be any predefined integer type the compiler wants, as long as it 
includes 1 and 5.

Thus the base type is NOT integer. However, the base type's range may well
be the same as integer's.

3.5.5(8) -

 Animal_ID'SUCC(Next_Animal) 

returns a value in the range of the BASE type of Animal_ID, which is the
range of whatever predefined type the compiler picked above. However, 
when this value is assigned back into Next_Animal, it is subject to a
constraint check on the 1..5 range. The constraint check doesn't HAVE to
happen, but it could.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Zoo question

[Bob Gilbert]

In article <3211C9C6.41C67EA6@escmail.orl.mmc.com>, Ted Dennison <dennison@escmail.orl.mmc.com> writes:
> Bob Gilbert wrote:
> > 
> > In article <320F16B6.6944@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> > > Here's a little brain teaser we received recently. Assuming no typos or
> > > other obvious syntax errors, will the Fill procedure work in Ada 83?
> > >
> > > package Zoo is
> > >
> > >   type Animal_ID is range 1 .. 5; -- yes, an enumeration type might be
> > 
> > I assume that the tricky part is that the attribute 'Succ operates
> > on the base type of Animal_ID, which is of type integer, and does not
> > consider the constraint 1 .. 5 (although the attributes 'First and
> 
> This didn't sound right to me, so its LRM time...
> 
> 3.5.4 -
> the type declaration is equivalent to -
> 
>    type integer_type is new predefined_integer_type;
>    subtype Animal_ID is integer_type range 1..5;
> 
> where integer_type is an ananoymous base type, snd predefined_integer_type
> can be any predefined integer type the compiler wants, as long as it 
> includes 1 and 5.
> 
> Thus the base type is NOT integer.

I guess I should have said that the base type of Animal_ID is *equivalent* to
or derived from type integer, at least as far as the constraints are concerned.

> However, the base type's range may well be the same as integer's.

As I would expect it to be.

> 3.5.5(8) -
> 
>  Animal_ID'SUCC(Next_Animal) 
> 
> returns a value in the range of the BASE type of Animal_ID, which is the
> range of whatever predefined type the compiler picked above. However, 
> when this value is assigned back into Next_Animal, it is subject to a
> constraint check on the 1..5 range. The constraint check doesn't HAVE to
> happen, but it could.

That's what I said (I think).  The attribute 'Succ is not constrained to
the specified range 1 .. 5, but I think I would expect a constraint check
to raise an exception when making the assignment back to Next_Animal.

-Bob

Re: Zoo question

[Bob Gilbert]

In article <3211EA8F.167EB0E7@escmail.orl.mmc.com>, Ted Dennison <dennison@escmail.orl.mmc.com> writes:
> 
> Close. However, integer is not the only predefined "integer type" allowed.
> Thus it could well be something like Short_Integer that the compiler 
> chooses to derive Animal_ID's base type from.
> 
> Of course this is a nit upon a nit. In effect if not in detail, you were
> correct (and at a certian level of detail, we are all incorrect).

Okay, although I would have (wrongly) assumed that type integer would
have been selected.  I guess the point is that the integer type eventually
used as the base type most likely won't have a constrained range of 1 .. 5,
and the attribute 'Succ uses the constraints of the base type, not any 
additional constraints imposed on it by the (implied) subtype.

> However, I should (and did) point out that the constraint check does NOT have
> to happen (and does not have to happen within the begin block). That is why 
> Ada (95) now has the 'valid attribute.

Right, so depending on the particular (Ada 83) compiler, the code may or 
may not produce the desired result, depending on whether the constraint
check is performed within the begin block or not.

-Bob

Re: Zoo question

[Ted Dennison]

Bob Gilbert wrote:
> 
> In article <3211C9C6.41C67EA6@escmail.orl.mmc.com>, Ted Dennison <dennison@escmail.orl.mmc.com> writes:
> > where integer_type is an ananoymous base type, snd predefined_integer_type
> > can be any predefined integer type the compiler wants, as long as it
> > includes 1 and 5.
> >
> > Thus the base type is NOT integer.
> 
> I guess I should have said that the base type of Animal_ID is *equivalent* to
> or derived from type integer, at least as far as the constraints are concerned.

Close. However, integer is not the only predefined "integer type" allowed.
Thus it could well be something like Short_Integer that the compiler 
chooses to derive Animal_ID's base type from.

Of course this is a nit upon a nit. In effect if not in detail, you were
correct (and at a certian level of detail, we are all incorrect).

> 
> > However, the base type's range may well be the same as integer's.
> 
> As I would expect it to be.

It may also be 1/2 the range, or 1/4, or 2*, or some bizzare unrelated 
range.

>>(more of my prattling deleted)
> 
> That's what I said (I think).  The attribute 'Succ is not constrained to
> the specified range 1 .. 5, but I think I would expect a constraint check
> to raise an exception when making the assignment back to Next_Animal.

Yes, that is what you said. The part that got me was saying that the base type
was integer. But the effect is (probably) the same.

However, I should (and did) point out that the constraint check does NOT have
to happen (and does not have to happen within the begin block). That is why 
Ada (95) now has the 'valid attribute.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Zoo question

[Ken Garlington]

Ted Dennison wrote:
> 
> OK. I'll bite. It looks like it would probably perform as advertised, with
> no optimization set on the compiler. The following constraint check code -
> 
> >
> >       Get_Next_Animal: begin -- look carefully at this code!
> >         Next_Animal := Animal_ID'Succ(Next_Animal);
> >       exception
> >         when others => Next_Animal := Animal_ID'First;
> >       end Get_Next_Animal;
> 
> isn't guaranteed to work (assuming "work" means raise an execption within
> this block when Animal_ID'Succ(Next_Animal) > Animal_ID'last).

You're getting warm (and doing much better than I did on my first look)!

Now, the question is: Even though the call to Animal_ID'Succ(Animal_ID'Last)
won't cause an exception (which I find very counter-intuitive, by the way),
will an exception be raised on the line that contains that call?

(You might want to read that statement more than once... :)

-- 
LMTAS - "Our Brand Means Quality"

Re: Zoo question

[Robert I. Eachus]

In article <321207F7.4D24@lmtas.lmco.com> Ken Garlington <garlingtonke@lmtas.lmco.com> writes:

  > Under what circumstances would it be acceptable to not generate a
  > range check when assigning a value of 6 to an object declared with
  > range 1 .. 5?

   Hardware failure or a program which was already erroneous. (Please,
no religous decussion over what forms of reasoning from erroneousness
are acceptable.  Save that for ARG meetings. ;-)

   Seriously the Zoo program as posted doesn't raise any serious
issues.  The programmer may expect the 'SUCC call to raise
Contraint_Error, but it will be raised immediately afterwords.  Now if
the variable is declared to be of the base type not the subtype, there
is a hard to find bug, but Ada makes it real hard to code that way.
In fact I suspect that that was the intended program, and it got
corrected automatically by the author as it was being typed in.

    I've run into this problem before in ARG discussions, it is often
hard to post code fragments which correctly demonstrate an anomaly
because my fingers automatically clean up the poor code as I type it.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Zoo question

[Robert A Duff]

In article <3212468B.2781E494@escmail.orl.mmc.com>,
Ted Dennison  <dennison@escmail.orl.mmc.com> wrote:
>   2 - No exception is ever raised (Constraint checking could be disabled 
>       for any number of reasons).

True, but one assumes that checks were not suppressed.  Otherwise,
*anyting* could happen.

>   3 - A CONSTRAINT_ERROR is raised OUTSIDE the block, upon the next attempt
>       to use the value of Animal_ID. (That's is what I meant by "within this
>       block" above).

I don't see how C_E could be raised outside the block.  11.6 allows the
compiler to play some games, but it does not allow the wrong handler to
handle an exception.  Nor does it allow an out-of-range value to be used
in any way that affects the external results of the program -- that is,
the compiler can re-order code to a certain extent, but it cannot put
the use of a value before a range check of that value if the normal
semantics requires otherwise.

11.6 was totally rewritten for Ada 95, but I don't think these
particular aspects changed.

- Bob

Re: Zoo question

[Ken Garlington]

Ted Dennison wrote:
> 
> Ken Garlington wrote:
> >
> > Ted Dennison wrote:
> > >
> > > isn't guaranteed to work (assuming "work" means raise an execption within
> > > this block when Animal_ID'Succ(Next_Animal) > Animal_ID'last).
> >
> > Now, the question is: Even though the call to Animal_ID'Succ(Animal_ID'Last)
> > won't cause an exception (which I find very counter-intuitive, by the way),
> > will an exception be raised on the line that contains that call?
> 
> Maybe, maybe not. I see three valid possibilities -
> 
>    1 - It raises an exception at the assignment. (This is what the code
>        seems to be assuming)

That certainly seems to be one of the options...

> 
>    2 - No exception is ever raised (Constraint checking could be disabled
>        for any number of reasons).

A valid point; for this example, assume that there's no pragma Suppress,
compiler switches, or other use actions applied that would disable checking.

> 
>    3 - A CONSTRAINT_ERROR is raised OUTSIDE the block, upon the next attempt
>        to use the value of Animal_ID. (That's is what I meant by "within this
>        block" above).

Assuming no supresses, would there be a case where #1 would not apply (no
exception on assignment)?

-- 
LMTAS - "Our Brand Means Quality"

Re: Zoo question

[Bob Gilbert]

In article <dewar.840110364@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
> LET'S CLEAN UP THE ANIMAL CAGES! :-)

{Thorough explanation of why sample would produce expected results, deleted}

> So, the mystery is, why is this a brain teaser for Ken. That must mean that
> he found it not working on some compiler. 

Or perhaps Ken just likes to throw out a bit of code that works,
imply that it doesn't, and see how badly some of us can embarrass
ourselves trying to explain why it might not work :-).

(Darn, I knew Ted's explanation about the constraint exception
not being guaranteed to occur inside the begin block sounded a
little suspect, but he just sounded so convincing.  I hate when
that happens).

-Bob

Re: Zoo question

[John Herro]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:
> Get_Next_Animal: begin -- look carefully at this code!
>    Next_Animal := Animal_ID'Succ(Next_Animal);
> exception
>    when others => Next_Animal := Animal_ID'First;
> end Get_Next_Animal;

     I realize that the point of this thread is to discuss the raising and
handling of Constraint_Error, but I think for the sake of any beginners
reading comp.lang.ada, we should point out the general rule not to use an
exception handler where a simple "if" will do.  Thus, I think most people
will agree that the above could better be written

if Next_Animal = Animal_ID'Last then
   Next_Animal := Animal_ID'First;
else
   Next_Animal := Animal_ID'Succ(Next_Animal);
end if;

     Again, I realize that's not the point of this thread, but I think
it's worth pointing out for the sake of beginners.

- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor

Re: Zoo question

[Keith Thompson]

In <3210A142.2781E494@escmail.orl.mmc.com> Ted Dennison <dennison@escmail.orl.mmc.com> writes:
> Ken Garlington wrote:
> > 
> > Here's a little brain teaser we received recently. Assuming no typos or
> > other obvious syntax errors, will the Fill procedure work in Ada 83?
> 
> OK. I'll bite. It looks like it would probably perform as advertised, with
> no optimization set on the compiler. The following constraint check code -
> 
> > 
> >       Get_Next_Animal: begin -- look carefully at this code!
> >         Next_Animal := Animal_ID'Succ(Next_Animal);
> >       exception
> >         when others => Next_Animal := Animal_ID'First;
> >       end Get_Next_Animal;
> 
> isn't guaranteed to work (assuming "work" means raise an execption within
> this block when Animal_ID'Succ(Next_Animal) > Animal_ID'last).

I believe it *is* guaranteed (by the language) to work.  In both Ada 83
and Ada 95, the Animal_ID'Succ attribute is a function that takes a
value of type Animal_ID'Base and returns a value of type Animal_ID'Base.
Since Animal_ID'Base will almost certainly have bounds greater than
1..5, Animal_ID'Succ(5) will return 6, without raising an exception.

However, attempting to assign the resulting value to Next_Animal *must*
raise Constraint_Error, since Next_Animal is of subtype Animal_ID and
is constrained to the range 1..5.

I can imagine a compiler implementer mistakenly thinking that the Succ
attribute returns a value of the prefix subtype, and optimizing out
the check.  If this is what you're seeing, it's clearly a compiler bug.

Incidentally, this worked as expected (i.e., properly raised
Constraint_Error) on every Ada 83 and Ada 95 compiler I tried.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As the most participatory form of mass speech yet developed, the Internet
deserves the highest protection from government intrusion." -- ACLU v. Reno

Re: Zoo question

[Robert A Duff]

In article <321207F7.4D24@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>Under what circumstances would it be acceptable to not generate a range
>check when assigning a value of 6 to an object declared with range 1 .. 5?

The only answer to the "brain teaser" I can think of, is that checks
were suppressed in some code containing the code shown (or globally, on
the command line or whatever).  If that's it, then I say, "No fair, it's
a trick question!"  ;-)

- Bob

Re: Zoo question

[Robert Dewar]

LET'S CLEAN UP THE ANIMAL CAGES! :-)

Ken's note here has sowed a lot of possibly confusing information, and it
always worries me that people may get the impression that Ada is all screwed
up, so lets unscrew things. Here is Ken's program, slightly modified to
add output and actually call Fill:

   with Text_IO; use Text_IO;
   procedure Zoo_Main is
   
      package Zoo is
      
        type Animal_ID is range 1 .. 5;
        -- yes, an enumeration type might be
        -- better, but it spoils the example!
      
        subtype Cage_ID is Positive range 1 .. 12;
      
        type Cage_Row is array (Cage_ID) of Animal_ID;
      
        -- Fill fills a row of cages with various animals, in
        -- sequential order with alternating animals
        procedure Fill ( Cages : in out Cage_Row );
      
      end Zoo;
      
      package body Zoo is
      
        procedure Fill ( Cages : in out Cage_Row ) is
          Next_Animal : Animal_ID := Animal_ID'First;
        begin -- Fill
          for Cage in Cages'Range loop
      
            Cages(Cage) := Next_Animal;
      
            Put_Line
              ("Cage " & Cage'Img & " contains animal " & Next_Animal'Img);
      
            Get_Next_Animal: begin -- look carefully at this code!
              Next_Animal := Animal_ID'Succ(Next_Animal);
            exception
              when others => Next_Animal := Animal_ID'First;
            end Get_Next_Animal;
      
          end loop;
        end Fill;
      
      end Zoo;
   
      use Zoo;
   
      CR : Cage_Row;
   
   begin
      Fill (CR);
   end;

Ken has been a little coy with this example, but his original post and a
followup strongly suggest that there is some mysterious justification for
the above code failing to work in the obvious manner.

The obvious expected output is (this comes out of GNAT):

  Cage  1 contains animal  1
  Cage  2 contains animal  2
  Cage  3 contains animal  3
  Cage  4 contains animal  4
  Cage  5 contains animal  5
  Cage  6 contains animal  1
  Cage  7 contains animal  2
  Cage  8 contains animal  3
  Cage  9 contains animal  4
  Cage  10 contains animal  5
  Cage  11 contains animal  1
  Cage  12 contains animal  2

No other output is correct, and on the face of it, no one would normally
think that this code is other than completely correct. Of course the
assignment:

   Next_Animal := Animal_ID'Succ(Next_Animal);

raises CE if the value is out of range, and the hander is entered, and
Next_Animal is set back to the First value.

So what is all the commotion about. From Ken's posts, the best guess is
that he has used a compiler with a serious bug in it that omits the
constraint check in this case (I say serious, because any bug that results
in unexpected wrong results is serious, much worse say than a blowup at
compile time). If this guess is correct, then Ken, please report the bug
to the compiler vendor.

That really is the end of the discussion, but since followup posts have
wandered off trying to justify some kind of incorrect execution. Let's
dig a little further. Those who just want their programs to work can
ignore this, and rest assured that Ken's quoted code is of course fine.

Let's look at the statement in question more closely:

   Next_Animal := Animal_ID'Succ(Next_Animal);

The call to Animal_ID'Succ (Next_Animal) of course does not raise an
exception, no more than Next_Animal  + 1 would. Arithmetic computations
work always with values of the base type -- this is pretty fundamental.
Ken commented that this is counter-intuitive, but it should not be.
If this seems counter-intuitive, then you don't quite have the right
view of subtypes and base types. Subtype constraints in effect apply
to objects, and limit what can be stored. Yes, in a few places, notably
conversions, range checks happen in expressions, but arithmetic, including
the normal arithmetic operators and Succ and Pred, always work with the
base type.

For example, it is quite fine to write

   Next_Animal := (- Next Animal) + 4;

even though -Next_Animal is of course out of range of the constraint for
Animal_ID. The only requirement is that the result be in range for the
assignment.

That requirement also applies to Ken's statement, so of course the assignment
raises constraint error when the value to be assigned to Next_Animal is out
of range of the subtype.

Note that in a screwy implementation with a base type with range -5 .. 5
which was used as the base type for this declared type, the program would
still work, though in that case it is the Succ call that would cause the
constraint error. This is a subtle distinction which most users would
not think about, and do not need to think about, since the result is a
Constraint_Error in either case.

So, the mystery is, why is this a brain teaser for Ken. That must mean that
he found it not working on some compiler. Well that's a bug! It should be
reported as such.

Ken, if you have run into such a bug, then I would guess that the compiler
implementor has made the mistake of assuming that the result of X'Succ is
always in range of X, which is of course wrong in this case, and thus thinks
they can get away with omitting the range check.

Now Ken, can you elucidate why you presented this example?

Now, since this works, in both Ada 83 and Ada 95 in the expected manner, the
mystery is why

However, the assignment to Next_Animal most certainly must raise a
constraint error if the value is out of range. I can imagine a compiler
having a bug here and failing to do the required constraint check (the
way this happens is if the implementor gets the handling of Succ right,
which is likely, there are ACVC tests), but gets confused into thinking
the constraint check can be omitted when it cannot in this case.

Remember that ALL assignmments have constraint checks, even A := A requires
a constraint check from a semantic point of view in Ada 83. It is just that
you can omit it in some cases (including A := A, but not including the
example above).

So the bottom line is that the code is fine, and if it does not work,
you have found a bug, you should report it. There is no change from
Ada 83 to Ada 95 that would affect the correct functioning of this
code.

-------------- replies to some follow on messages ------------

From Ken:

  "That certainly seems the intuitively obvious answer to me. Does anyone vote
  for a row of cages filled with 1 .. Cages'Last?"

No one should vote for that alternative, it is clearly wrong. If you have
a compiler that votes for that alternative, the compiler is wrong!

---------
From Ted:
---------

  "returns a value in the range of the BASE type of Animal_ID, which is the
  range of whatever predefined type the compiler picked above. However,
  when this value is assigned back into Next_Animal, it is subject to a
  constraint check on the 1..5 range. The constraint check doesn't HAVE to
  happen, but it could."

Yes, it does have to happen. You have been fooled into thinking otherwise
by the original question, which incorrectly implied that the code did not
work as expected.

---------
From Ted:
---------

  "However, I should (and did) point out that the constraint check does
  NOT have to happen (and does not have to happen within the begin block).
  That is why Ada (95) now has the 'valid attribute."

That's very confused and is wrong. Of COURSE constraint checks are required
if the variable on the left side of an assignment is of a subtype with
a constraint.

Of COURSE this fundamental requirement has not changed in Ada 95.

The 'Valid attribute has nothing at all to do with the case, it is for use
in cases where by various means you manage to get an abnormal or undefined
value into a variable (e.g. it is uninitialized, set by a bad unchecked
conversion, read from a stream, etc.)

But assignment can never leave an abnormal result in the absence of a
raising of an exception. In our case here:

           Next_Animal := Animal_ID'Succ(Next_Animal);


in practice, the right side evaluation will NOT raise a CE. It is if
you are being fanatically formal allowable to raise CE during evaluation
of the right side (if Animal_Id'Base'Last = 5), and that CE, if you are
being fanatically formal, could leave Next_Animal with an abnormal value,
but in any case the exception would be raised and Next_Animal is reset
in either case.

This example is straightforward and works fine. As I suggested in a previous
posting, I suspect that some compiler bug has given rise to this whole
thread of confusing speculations!

---------
Bob said:
---------

  "Right, so depending on the particular (Ada 83) compiler, the code may or
  may not produce the desired result, depending on whether the constraint
  check is performed within the begin block or not."

Nope, this is wrong. The code will always work. There is no authorization
for moving this constraint check out of the frame.

---------
Ted said:
---------

"Maybe, maybe not. I see three valid possibilities -

   1 - It raises an exception at the assignment. (This is what the code
       seems to be assuming)

   2 - No exception is ever raised (Constraint checking could be disabled
       for any number of reasons).

   3 - A CONSTRAINT_ERROR is raised OUTSIDE the block, upon the next attempt
       to use the value of Animal_ID. (That's is what I meant by "within this
       block" above).
"


Possibility 1 is certainly correct
Possibility 3 is definitely NOT correct. The reason I am reemphasizing
 this is that to me the suggestion that this might not work and cannot
 be relied on may be very unsettling to those who do not know Ada well
 enough to be confident that statements like this are false. Of COURSE
 the CE is caught by the handler, you can move CE's around a bit, but
 not outside the frame. Since we are talking Ada 83 here (though Ada 95
 is no different), let's quote from the Ada 83 RM, 11.6(4) says

  second, for each operation, the innermost enclosing frame or accept
  statement mnust be the same in the alternative order as in the canonical
  order, and the same exception handlers must apply.

As to possibility 2, yes, certainly if you suppress constraint errors
this code will not work.

In GNAT, we have introduced a pragma Unsuppress, which undoes the effect
of any Suppress (either from the command line switch or from a pragma
Suppress). We use Unsuppress to emphasize that we are relying on certain
checks for correctness of the code (if you want to see some examples of
this use, look in the file a-tiinio.adb -- the body of Integer_IO).

I hope this clears things up. One suggestion I have in this situation is
to run code like this with GNAT. Then if the GNAT output surprises you,
investigate further, since GNAT is not always right, but it is also not
always wrong, and it is quite likely that when GNAT surprises you, GNAT
is right and you are wrong. If we look at all the reports that are sent
to us, many identify bugs in GNAT which we fix, but a far larger number
are confusions of expectations on the part of the person asking the
question. 

Re: Zoo question

[Bob Gilbert]

In article <321207F7.4D24@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> Bob Gilbert wrote:
> > 
> > Right, so depending on the particular (Ada 83) compiler, the code may or
> > may not produce the desired result, depending on whether the constraint
> > check is performed within the begin block or not.
> 
> Under what circumstances would it be acceptable to not generate a range
> check when assigning a value of 6 to an object declared with range 1 .. 5?

Geez... did I actually type that?  I guess the only acceptable way to not
generate the range check would be to compile with the checking turned off.

-Bob

Re: Zoo question

[Ken Garlington]

Robert Dewar wrote:

> Now Ken, can you elucidate why you presented this example?

We had a user report what appeared to be a code generation error against one of our
compilers (the specific vendor to be nameless, for reasons which will become
clear). The code was generating cage values as 1,2,3,4,5,_6_, etc. The
response from the vendor was, "That's not a bug, Succ works on the base type."
We checked, and of course Succ does work on the base type. However, as was
noted, that's not relevant to the example. So, I decided to post the example,
without an opinion as to whether it would work or not, and see who was right
(us or the vendor). Thanks for all the input; we will include it when we
resubmit the problem.

-- 
LMTAS - "Our Brand Means Quality"

Re: Zoo question

[Robert Dewar]

John Herro said

"     I realize that the point of this thread is to discuss the raising and
handling of Constraint_Error, but I think for the sake of any beginners
reading comp.lang.ada, we should point out the general rule not to use an
exception handler where a simple "if" will do.  Thus, I think most people
will agree that the above could better be written

if Next_Animal = Animal_ID'Last then
   Next_Animal := Animal_ID'First;
else
   Next_Animal := Animal_ID'Succ(Next_Animal);
end if;"

Actually this is nice application for a modular type, just make the
type be mod 5, then you just do the Succ call and it works fine.
No if needed, no test needed.

Re: Zoo question

[Robert Dewar]

Ken asks

"Assuming no supresses, would there be a case where #1 would not apply (no
exception on assignment)?"

No, the code you wrote MUST give an exception on the assignment. Any
speculation to the contrary is simply misinformed, any compiler that
does not raise the exception (assuming checks are turned on) is simply
broken, and it is a bug. 

Re: Zoo question

[John Herro]

dewar@cs.nyu.edu (Robert Dewar) writes:
> Actually this is nice application for a modular type
     Absolutely!  That's the first thing that came to my mind when I read
the original post.  I *think* that's why the original post said Ada 83,
but of course I'm not at all certain that's the reason.
- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor
I have a spelling checker;
   It came with my PC;
It plainly marks four my review
   Mistakes I cannot sea;
I've run this poem threw it;
   I'm sure you please to no
Its letter perfect in it's weigh;
   My checker tolled me sew.

Re: Zoo question

[Ted Dennison]

Bob Gilbert wrote:
> 
> In article <321207F7.4D24@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> > Bob Gilbert wrote:
> > >
> > > Right, so depending on the particular (Ada 83) compiler, the code may or
> > > may not produce the desired result, depending on whether the constraint
> > > check is performed within the begin block or not.
> >
> > Under what circumstances would it be acceptable to not generate a range
> > check when assigning a value of 6 to an object declared with range 1 .. 5?
> 
> Geez... did I actually type that?  I guess the only acceptable way to not
> generate the range check would be to compile with the checking turned off.

...or the check could be placed around the next USE of the value. This could
well be a useful optmization in some circumstances.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Zoo question

[Ted Dennison]

Robert Dewar wrote:
> 
> Ken asks
> 
> "Assuming no supresses, would there be a case where #1 would not apply (no
> exception on assignment)?"
> 
> No, the code you wrote MUST give an exception on the assignment. Any
> speculation to the contrary is simply misinformed, any compiler that
> does not raise the exception (assuming checks are turned on) is simply
> broken, and it is a bug.

That does seem to jibe with 5.2(3-4) in my Ada 83 LRM. However, I could
have sworn I saw a rather long discussion here a year ago about compiler
optimizations moving constraint checks out of loops. I suppose this is
still possible, as long as there aren't any declare blocks (or is it?).
-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Zoo question

[Ken Garlington]

John Herro wrote:
> 
> dewar@cs.nyu.edu (Robert Dewar) writes:
> > Actually this is nice application for a modular type
>      Absolutely!  That's the first thing that came to my mind when I read
> the original post.  I *think* that's why the original post said Ada 83,
> but of course I'm not at all certain that's the reason.

That, along with the fact that using "Ada" in general should imply Ada 95,
while this was an Ada 83-only compiler.

-- 
LMTAS - "Our Brand Means Quality"

Re: Zoo question

[Mark A Biggar]

In article <32185FC3.2781E494@escmail.orl.mmc.com> Ted Dennison <dennison@escmail.orl.mmc.com> writes:
>Robert Dewar wrote:
>> Ken asks
>> "Assuming no supresses, would there be a case where #1 would not apply (no
>> exception on assignment)?"
>> No, the code you wrote MUST give an exception on the assignment. Any
>> speculation to the contrary is simply misinformed, any compiler that
>> does not raise the exception (assuming checks are turned on) is simply
>> broken, and it is a bug.
>That does seem to jibe with 5.2(3-4) in my Ada 83 LRM. However, I could
>have sworn I saw a rather long discussion here a year ago about compiler
>optimizations moving constraint checks out of loops. I suppose this is
>still possible, as long as there aren't any declare blocks (or is it?).

Even a declare block doesn't prevent that optimization, but if that
declare block has a exception handler you can't move any code that
could possibly raise the exception outside the block.  Exceptions must be
caughts by the inner most hadler for the exception that encloses the 
code that raises the exception.  Adn, yes this does restorct the use of
code moving optimizations, but anyother rule would cause choas.

--
Mark Biggar
mab@wdl.lmco.com

Re: Zoo question

[Ted Dennison]

Bob Gilbert wrote:
> 
> (Darn, I knew Ted's explanation about the constraint exception
> not being guaranteed to occur inside the begin block sounded a
> little suspect, but he just sounded so convincing.  I hate when
> that happens).

A little more practice and I'll be ready to go talk to HR about my
next raise. :-)


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Zoo question

[Ted Dennison]

Robert Dewar wrote:
> 
> Ken has been a little coy with this example, but his original post and a
> followup strongly suggest that there is some mysterious justification for
> the above code failing to work in the obvious manner.

Yeah, I think its about time for Ken to tell us what he's seeing.

> The 'Valid attribute has nothing at all to do with the case, it is for use
> in cases where by various means you manage to get an abnormal or undefined
> value into a variable (e.g. it is uninitialized, set by a bad unchecked
> conversion, read from a stream, etc.)

I've been burned so many times in the above cases, that I have developed 
a rather cynical attitude towards constraint checking. Its nice to see that
there are some cases where you CAN count on it (assuming it hasn't been 
supressed, or compiled with Ken's compiler).

> Possibility 3 is definitely NOT correct. The reason I am reemphasizing
>  this is that to me the suggestion that this might not work and cannot
>  be relied on may be very unsettling to those who do not know Ada well
>  enough to be confident that statements like this are false. Of COURSE
>  the CE is caught by the handler, you can move CE's around a bit, but
>  not outside the frame. Since we are talking Ada 83 here (though Ada 95
>  is no different), let's quote from the Ada 83 RM, 11.6(4) says
> 
>   second, for each operation, the innermost enclosing frame or accept
>   statement mnust be the same in the alternative order as in the canonical
>   order, and the same exception handlers must apply.

Ahh. That's the piece I was missing. I knew it could be moved. I had just
never heard the limitations before. Out of curiosity, what counts as a 
"frame"? Is it just subprograms and "begin" blocks?

> 
> As to possibility 2, yes, certainly if you suppress constraint errors
> this code will not work.
> 
> In GNAT, we have introduced a pragma Unsuppress, which undoes the effect
> of any Suppress (either from the command line switch or from a pragma

Interesting...

Do you have a "resuppress" compiler option? :-)  


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Zoo question

[Robert Dewar]

T.E.D. said

"That does seem to jibe with 5.2(3-4) in my Ada 83 LRM. However, I could
have sworn I saw a rather long discussion here a year ago about compiler
optimizations moving constraint checks out of loops. I suppose this is
still possible, as long as there aren't any declare blocks (or is it?)."

I hope this is clear now, but this is wrong. Furthermore. 52.(3-4) has
nothing to do with the case (except that it is where the canonical order
in which the constraint error is clearly raised at the assignment, is
described). In the absence of permission for movinbg things around in
11.6, this would be decisive, but there is no rule in 11.6 that allows
moving an exception outside its proper exception frame (the language
would be completely useless if this were allowed).

Re: Zoo question

[Robert Dewar]

Ted Dennison says, referring to the Zoo example

"...or the check could be placed around the next USE of the value. This could
well be a useful optmization in some circumstances."

This transformation is only allowed if it is semantically invisible, and
hence does not need to enter into a discussion of the semantics of the Zoo
program. note in particular that such a transformation is not permitted
if it changes any external effect, or if it moves a CE outside the
current frame.