Re: obsolete ascii? (for language lawyers)

[Keith Thompson <kst@cts.com>]

Robert Dewar <robert_dewar@my-deja.com> writes:
> 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.

Ok, I was making some (possibly invalid) assumptions.  I wasn't
closely involved in the design process, so everything I say here is
merely my opinion.  In fact, feel free to assume that anything I say
anywhere is merely my opinion.

Note that I tend to be prejudiced in favor of clean, coherent design
over backwards compatibility.  I recognize the need for backwards
compatibility, but I tend to grit my teeth a bit when I see features
that seem to exist only for that reason.  I don't expect everyone to
share this prejudice.

With that in mind, let's go through Annex J.

J.1 Renamings of Ada 83 Library Units.

I really like the idea of making all the language-defined library
units children of a small number of parent units (Ada, System, and
Interfaces).  It avoids polluting the user's namespace, and
(hopefully) encourages vendors and other users to do the same kind of
thing -- like the GNAT.* hierarchy.  By adopting a uniform style of
referring to Ada.Text_IO rather than Text_IO, one can avoid having to
worry about the fact that Text_IO has a top-level renaming, but
Wide_Text_IO doesn't.  If this feature were in the language for any
reason other than backward compatibility, it wouldn't be limited to
the units that were defined in Ada 83.

(Robert mentions that Unchecked_Conversion is really more a
fundamental feature of the langauge than a library package.  Perhaps
it should have been made an attribute.  I don't think this is terribly
relevant to the subject at hand, though.)

J.2 Allowed Replacements of Characters

Ada 83 allowed users to use ! for |, : for # (in based literals), and
% for ".  There were (barely) good reasons for this at the time; it
would have been better (IMHO) to implement preprocessors for those
rare systems that couldn't use |, #, and ".  Ada 95 still allows these
replacements.  When someone starts an Obfuscated Ada contest, we'll be
ready.

J.3 Reduced Accuracy Subtypes

I don't think I've ever used these.  An accuracy constraint isn't
really a "constraint" in the sense that a range constraint is; it only
affects certain predefined attributes and, indirectly, the behavior of
the predefined I/O packages.  A note in the AARM suggests the idea of
replacing this with an attribute definition clause, which I think
would have been cleaner if not for the need for backwards
compatibility.

J.4 The Constrained Attribute

As the AARM says, the Ada 83 definition of this attribute (for
subtypes) was confusing, and the introduction of private subtypes just
makes it worse.  I don't have anything to add here.

J.5 ASCII

Yes, Ada.Characters.Latin_1 is more verbose than ASCII, but it also
covers the entire character set that Ada 95 is required to support.
If the language were being designed from scratch, it wouldn't make
sense to have both.  If you want to refer to names like BEL directly,
you only have to type
    with Ada.Characters.Latin_1;
    use Ada.Characters.Latin_1;
once per compilation unit.

J.6 Numeric_Error

I think we can all agree this is obsolete, and is still there only for
backward compatibility reasons.  There's no reason to use it in new
code, unless you need strict Ada 83 compatibility (which hardly seems
necessary these days).  (For the record, I suggested raising
Constraint_Error rather than Numeric_Error in TeleSoft's compiler, but
I was overruled.)

J.7 At Clauses

I think this is a clear example of a feature for which there's a
better alternative in Ada 95 ("for foo use at expr" replaced by
"for foo'address use expr").

J.7.1 Interrupt Entries

I haven't used these much.  I'll take your word for it that the old
form is still useful.

J.8 Mod Clauses

See At Clauses.

J.9 The Storage_Size Attribute

The Storage_Size pragma, which allows a different Storage_Size to be
specified for each task object, makes the 'Storage_Size of a task type
questionably meaningful.

> > 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!)

Right, and that's why it's in Annex J, yes?

> > 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.

I have.

> > 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.

There is an absolute standard that defines "bad style" as "what Keith
Thompson doesn't like".  8-)}  Isn't style always a matter of opinion?
Hopefully informed opinion, of course.  Naturally, everyone should
agree with mine.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.