Re: obsolete ascii? (for language lawyers)

[Robert Dewar <robert_dewar@my-deja.com>]

In article <yecemiq75ww.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:

> more important reason, however, is to let people know that
> there's a newer, better way to do the same thing.  These are
> features that are in the language *only* to support legacy
> code; if the language were being designed from scratch today,
> they wouldn't be there.

No, you cannot conclude any of the above. All you can conclude
is that certain people and in particular the design team,
thought that some of the above were true.

Those of us who disagreed in some cases did not argue strongly,
because, at least speaking for myself, I did not care if
features ended up in annex J or not.

For example, I happen to think that the way that Ada 83 maps
interrupts is much cleaner and higher level than the method
in Ada 95 which is deliberately chosen to be lower level and
closer to the way some hardware works (not all hardware
incidentally, most computers in the world, powered by ia32 chips
have hardware that maps very nicely the semantic model of Ada 83
interrupts (although I doubt any Ada implementation has taken
advantage of this).

> I wouldn't use '%' as a string literal delimiter

Neither would I, but not because someone put this feature into
Annex J, but rather because the reason for this feature (input
devices lacking the clearer quote sign) have disappeared from
sight, so it makes no sense to use it (this is true of those
writing Ada 83 today as well!)

> or write a context clause for Text_IO (rather than
> Ada.Text_IO)

Fine you are welcome to this opinion, but please form it for
OTHER reasons than the fact that this is in Annex J. Personally
I see no reason whatever to type the 4 or 8 (use) extra
characters, since there is no possibility of generating any
confusion on the part of the reader by using Text_IO rather
than Ada.Text_IO, and I actually find Unchecked_Conversion
nicer than Ada.Unchecked_Conversion, since this really should
be a fundamental language feature, and I see no reason why the
reader needs the reminder of the fiction that it is a library
package, let alone to need to be reminded of exactly where to
find this bogus library package (bogus because some
implementation magic will always be required for UC!)

> or a handler for Numeric_Error, in new code

Again, no well written Ada 83 code has handlers for
Numeric_Error either, since Ada 83 compilers are encouraged
to treat CE and NE the same, Ada 95 style, and have been for
many many years. Yes, some annoying compilers refused to follow
this implementation advice :-)

> not because I expect any of those
> features to vanish, but because it's bad style.

No, that's wrong, there is no absolute standard that says it
is bad style. Not even the RM says this, it says:

1   This Annex contains descriptions of features of the language
whosefunctionality is largely redundant with other features
defined by thisInternational Standard.  Use of these features is
not recommended in newly written programs.

Note here that the RM claims only "largely redundant", not the
much stronger claim from Keith that there is always a newer
and better way of doing things. And it does not say that the
reason for the recommendation is that it is bad style. Indeed
the understanding when the design team presented Annex J was
always that the reason for this recommendation was that these
features might disappear in the future.

So what we are left with is really that *Keith* thinks it is
bad style. Fine, everyone has different stylistic views. The
next time you are deciding whether to write Text_IO or
Ada.Text_IO, it is perfectly appropriate to choose what *you*
think is the right style, if you like you can let yourself
be influenced by the stylistic preferences of Keith or Robert
or anyone else, but you should not accept Keith's claim that
there is some definite higher authority that declares that
using Annex J features is bad style :-)

I actually did worry a bit that people would adopt Keith's
attitude, and you can easily see inflexible management turning
this into a prohibition without sufficient thought. This is why
I worked hard to get pragma Elaborate moved out of Annex J,
since that for *sure* was functionality that is needed (if you
think Elaborate_All replaces it, you have not tried to port
some large legacy programs :-)

At this stage, there is not much left in Annex J (we did work
to pull stuff out!) The remaining items are

package renamings -- use them freely why not?

character replacements -- unnecessary for the most part. A
possible exception is if you are using certain funny European
keyboards (actually some people in WG9 claimed that the bar
replacement was essential).

Reduced accuracy subtypes -- useful for controlling I/O
behavior in some situations (there was an attempt to remove
these completely from the language -- this useful application
was pointed out, and a compromise put them back in, but only in
Annex J.

Constrained attribute on private types. Probably only useful
in legacy code.

ASCII. Very useful, it is an annoying amount of typing to have
to say

with Ada.Characters.Latin_1

and then

Ada.Characters.Latin_1.Bel

instead of simply Ascii.Bel in a unit that needs this
single reference. Furthermore the Latin_1 package puts piles
of junk symbols that are almost certainly of no use into
your name space.

I find the insistence on using Ada.Characters.Latin_1 to be
excessive Ada pedantry, and you should not for a moment be
intimidated into writing all this nonsense unless *YOU*
prefer to write it, and think it makes things clearer.

Numeric_Error, this is only relevant if you are writing code
that is intended to be portable between Ada 95 and Ada 83 (some
people are still in this situation), in which case you should
write

   when Constraint_Error | Numeric_Error =>

(and I hope you do not have too many such handlers, code with
lots of explicit Constraint_Error handlers is suspect!)

At clauses. Obsolete indeed, the new address clause is cleaner
and more consistent, but no particular reason to go changing
legacy code. No reason to use this in new code.

Interrupt entries. As mentioned above, a nice feature. One has
to hope that one's compiler implements this nice feature :-)

Mod clauses. Same comments apply as for at clauses.

Storage_Size. I don't really see why this is obsolete. The
alternate pragma form is fine, but in some ways the Ada 83
style is more consistent with other Ada 95 syntax.


> (I wonder how many Ada programmers even know that this:
>
>     with Text_IO;
>     procedure Obsolesce is
>         X : Integer := 16:FF:;
>     begin
>        Text_IO.Put_Line(%X = % & Integer'Image(X));
>     end Obsolesce;
>
> is valid.)

Well the fact is that any competent Ada programmer should have
at least read through the features of the language, and these
features include Annex J. It is certainly possible that you
may meet the % in existing code, and a programmer who knows
the features of Ada including this one, is better off than
one who does not!

> On the other hand, if you have legacy code that uses these
> features, it's not worth going back and changing it

Indeed!

> unless you're doing a major rewrite anyway.

And maybe not even then, don't fix things that are not broken.
In some cases, the fixes may not be completely trivial
(certainly true for the interrupt case for example, and for
reduced accuracy subtypes -- it may be QUITE difficult to
determine if reduced accuracy subtypes have some significant
function -- for example one of our customers was using reduced
accuracy subtypes to define larger epsilon values to be used
in comparison of floating-point values).

Robert Dewar


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.