From: Charles H. Sampson on
<tmoran(a)acm.org> wrote:

> > And it would be desirable, because in most cases the explicit
> > "mod" (or "%") is more readable.
>
> I := Ring_Indices'succ(I);
> vs
> I := (I + 1) mod Ring_Size;
> or
> Bearing := Bearing + Turn_Angle;
> vs
> Bearing := (Bearing + Turn_Angle) mod 360;

I'd be interested in hearing reactions to something I did. About a
year ago I had reason to do something similar to the Bearing/Turn_Angle
example. To avoid having to do a lot of background, I'll just restate
what I did in terms of Bearing/Turn_Angle.

Bearing and Turn_Angle as integers are way too inaccurate for the
application I was working on, which involved real-time position
calculations at a high rate. So Bearing and Turn_Angle were defined as
two (distinct) types derived from Long_Precision. (They were defined as
types because "Bearing" and "Turn_Angle" are non-specific nouns. See
the Ada Style Guide.)

I then overloaded "+" and "-" for (Bearing, Turn_Angle) arguments
and Bearing return value. In those functions is where the mod 360
occurred. (Actually, mod 360.0, as it were.)

There were two advantages to doing that. The more important was
that previously both of the kinds of values were being represented as
subtypes of Long_Precision and programmers would occasionally
interchange them and cause big debugging problems. The second was
removing the "mod" from sight, which allowed the programmers to simply
think of taking a bearing, turning an angle, and getting the resulting
bearing, without worrying about all the niceties that might be going on
inside "+".

Of course, new programmers coming on the project had to be taught
about the overloads and that they should not be writing elaborate
if-then-elses when they wanted to turn the ship.

Charlie
--
All the world's a stage, and most
of us are desperately unrehearsed. Sean O'Casey
From: anon on
In <8cf0fkF60rU1(a)mid.individual.net>, Niklas Holsti <niklas.holsti(a)tidorum.invalid> writes:
>Yannick Duchêne (Hibou57) wrote:
>> Le Wed, 11 Aug 2010 01:28:25 +0200, Yannick Duchêne (Hibou57)
>> <yannick_duchene(a)yahoo.fr> a écrit:
>>> In “11.5 Suppressing Checks”:
>>> 4/2 pragma Suppress(identifier [, [On =>] name]);
>> Strange. I've noticed it with the reply to you : the “[, [On =>] name]”
>> appeared in the message while it is not visible in my reference. May be
>> some trouble with the HTML version I use.
>
> [ snip ]
>
>> This is no more valid Ada (well.... this is still valid Ada 95, this is
>> just not more valid Ada 2005/2012)
>
>In the Ada 2005 RM, see section J.10 (Obsolescent Features: Specific
>Suppression of Checks).
>
>--
>Niklas Holsti
>Tidorum Ltd
>niklas holsti tidorum fi
> . @ .

Since, all Ada compilers except for GNAT and IBM are still using Ada 83 or
95 standard the "pragma Suppress ( identifier [ , [ On => ] name ] ) ;"
statement is still valid.

Plus with GNAT having all of the standards within one compiler, GNAT should
allows this version plus the new version as well.



From: Georg Bauhaus on
On 11.08.10 13:58, anon(a)att.net wrote:

> Since, all Ada compilers except for GNAT and IBM are still using Ada 83 or
> 95 standard the "pragma Suppress ( identifier [ , [ On => ] name ] ) ;"
> statement is still valid.

The AppletMagic compiler (using the AdaMagic front end) has let me see
some hints to Ada 2005 features a few years ago. So I think it is safe
to assume that AdaMagic supports Ada 95, and Ada 2005 to some extent.
(Another possible hint is, I think, its being used in a current project
in Britain IIRC, an embeeded one. Someone reported here, recently.)


Georg
From: Robert A Duff on
Niklas Holsti <niklas.holsti(a)tidorum.invalid> writes:

> Yannick Duch�ne (Hibou57) wrote:
>> This is no more valid Ada (well.... this is still valid Ada 95, this
>> is just not more valid Ada 2005/2012)
>
> In the Ada 2005 RM, see section J.10 (Obsolescent Features: Specific
> Suppression of Checks).

Right. And things in the "Obsolescent Features" annex are perfectly
good Ada, and all Ada compilers are required to support them.
These features are "obsolescing" so slowly that they will never
actually become "obsolete". ;-)

That's my prediction, given that I've never heard anyone on the
ARG suggest that they should eventually be removed from the
standard.

- Bob
From: Robert A Duff on
csampson(a)inetworld.net (Charles H. Sampson) writes:

> <tmoran(a)acm.org> wrote:

>> Bearing := (Bearing + Turn_Angle) mod 360;
>
> I'd be interested in hearing reactions to something I did. ...

> I then overloaded "+" and "-" for (Bearing, Turn_Angle) arguments
> and Bearing return value. In those functions is where the mod 360
> occurred. (Actually, mod 360.0, as it were.)
>
> There were two advantages to doing that. The more important was
> that previously both of the kinds of values were being represented as
> subtypes of Long_Precision and programmers would occasionally
> interchange them and cause big debugging problems. The second was
> removing the "mod" from sight, which allowed the programmers to simply
> think of taking a bearing, turning an angle, and getting the resulting
> bearing, without worrying about all the niceties that might be going on
> inside "+".

Sounds to me like a good way to do things. It would still be a good
idea if you called it "Turn_Left" or something like that, instead
of "+". But I don't object to "+".

I object to having built-in support for angle arithmetic in the
language, though.

Did you eliminate meaningless ops like "*"? You could do that
by making the types private, but then you lose useful things
like literal notation. Or you could declare "*" to be
abstract, which is an annoyance, but might be worth it.

- Bob