obsolete ascii? (for language lawyers)

obsolete ascii? (for language lawyers)

[Peter Hermann]

LRM A.1(36) states an obsolete package ASCII.

now look at my example:

                     with text_io;
procedure hello is
   bell : character := character'val(7);
 --bell2 : character := bel;  -- is not allowed  :-(
begin
   text_io.put_line ("Hallo Welt..." & ascii.bel & bell);
   end hello;

What is the reason for this degradation?
Why then (zum Kuckuck!) is package ascii declared obsolete?

------------------

An additional remark:
text_io.put_line(ascii.bel); is not allowed,
because put_line (in contrast to put) does not
allow single characters as parameters.
This is hard to explain to a beginner and
therefore a nasty design decision for text_io:
having to obey to special cases.
Moreover, one could never say:
'put_line' is a combined 'put' and a 'new_line',
for the sake of simplicity.

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: obsolete ascii? (for language lawyers)

[John Herro]

 Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> writes:
> with text_io;
> procedure hello is
>    bell : character := character'val(7);
>  --bell2 : character := bel;  -- is not allowed  :-(
> begin
>   text_io.put_line ("Hallo Welt..." & ascii.bel & bell);
> end hello;

Although ASCII is part of package Standard, and Standard is automatically
WITHed and USEd in every compilation, ASCII isn't automatically USEd.  You must
make use of dot notation or explicitly USE ASCII.
The above will compile, even with the declaration of bell2 uncommented, if you
write "ASCII.bel" instead of "bel" or write "use ASCII;" immediately AFTER
"procedure hello is".
- John Herro
You can download a shareware AdaTutor program at
http://members.aol.com/AdaTutor

Re: obsolete ascii? (for language lawyers)

[David C. Hoos, Sr.]

Peter Hermann wrote in message
<7las7v$5p0$1@infosun2.rus.uni-stuttgart.de>...
>LRM A.1(36) states an obsolete package ASCII.
>
>now look at my example:
>
>                     with text_io;
>procedure hello is
>   bell : character := character'val(7);
> --bell2 : character := bel;  -- is not allowed  :-(
>begin
>   text_io.put_line ("Hallo Welt..." & ascii.bel & bell);
>   end hello;

>What is the reason for this degradation?

You would need a use clause for package ASCII, or use dot notation.

>Why then (zum Kuckuck!) is package ascii declared obsolete?

Because a package like Ada.Characters.Latin_1 replaces it, and
extends the range to include 256 characters instead of 128.

Re: obsolete ascii? (for language lawyers)

[Ted Dennison]

In article <7lb7ri$2g2@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> Peter Hermann wrote in message
> <7las7v$5p0$1@infosun2.rus.uni-stuttgart.de>...

> >Why then (zum Kuckuck!) is package ascii declared obsolete?
>
> Because a package like Ada.Characters.Latin_1 replaces it, and
> extends the range to include 256 characters instead of 128.

Also, ASCII is an obsolete American standard, while Latin_1 is an
international standard that fits into the "Unicode" universal
character standard.

--
T.E.D.


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

Re: obsolete ascii? (for language lawyers)

[Peter Hermann]

Thanks to John Herro,  David C. Hoos, Sr.,  Ted Dennison.
I am afraid I did not explain my question precisely enough.
With Ada95 we have a quite better type character, but
I can't see any reason why i should not have the possibility
to directly write down e.g. the bel-character, the ff-character,
the cr-character, the esc-character etc. etc. as a simple identifier,
the comfort of which will be removed as soon as the
'obsolete' package ascii will be removed!
We even cannot write something like character'(bel) or the like.
Sort of latin1.bel could do it? 
Are there better ideas? Or did I miss a given feature?

Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote:
> LRM A.1(36) states an obsolete package ASCII.
>
> now look at my example:
>
>                      with text_io;
> procedure hello is
>    bell : character := character'val(7);
>  --bell2 : character := bel;  -- is not allowed  :-(
> begin
>    text_io.put_line ("Hallo Welt..." & ascii.bel & bell);
>    end hello;

> What is the reason for this degradation?
> Why then (zum Kuckuck!) is package ascii declared obsolete?

> ------------------

> An additional remark:
> text_io.put_line(ascii.bel); is not allowed,
> because put_line (in contrast to put) does not
> allow single characters as parameters.
> This is hard to explain to a beginner and
> therefore a nasty design decision for text_io:
> having to obey to special cases.
> Moreover, one could never say:
> 'put_line' is a combined 'put' and a 'new_line',
> for the sake of simplicity.

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: obsolete ascii? (for language lawyers)

[Peter Hermann]

John Herro <johnherro@aol.com> wrote:

> Although ASCII is part of package Standard, and Standard is automatically
> WITHed and USEd in every compilation,

No. Package Standard is embracing every Ada program, i.e. 
your main procedure and all your subroutines are "part of" standard,
they are inside the declaration scope of standard.

> ASCII isn't automatically USEd.  You must
> make use of dot notation or explicitly USE ASCII.

Package ascii is, following the above, on the same level as your
programs. In this way a required dot notation or an explicite with
and use is reasonable.

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: obsolete ascii? (for language lawyers)

[Ted Dennison]

In article <7lhqs9$9c$1@infosun2.rus.uni-stuttgart.de>,
  Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote:
> Thanks to John Herro,  David C. Hoos, Sr.,  Ted Dennison.
> I am afraid I did not explain my question precisely enough.
> With Ada95 we have a quite better type character, but
> I can't see any reason why i should not have the possibility
> to directly write down e.g. the bel-character, the ff-character,
> the cr-character, the esc-character etc. etc. as a simple identifier,
> the comfort of which will be removed as soon as the
> 'obsolete' package ascii will be removed!

I'm not entirely sure I understand your problem. Latin_1 has all those
characters. Is it just that "Characters.Latin_1.BEL" takes up more
columns in your source file than "ASCII.BEL"? There are a number of easy
ways to fix that. If you want, you could even do the following:

   package ASCII renames Characters.Latin_1;

..and you'd be able to write your code very much like you used to.



--
T.E.D.


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

Re: obsolete ascii? (for language lawyers)

[Ted Dennison]

In article <7lih9i$ckb$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> characters. Is it just that "Characters.Latin_1.BEL" takes up more

>    package ASCII renames Characters.Latin_1;

Yikes! Make both those "Ada.Characters.Latin_1".

--
T.E.D.


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

Re: obsolete ascii? (for language lawyers)

[Robert A Duff]

Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> writes:

> Thanks to John Herro,  David C. Hoos, Sr.,  Ted Dennison.
> I am afraid I did not explain my question precisely enough.
> With Ada95 we have a quite better type character, but
> I can't see any reason why i should not have the possibility
> to directly write down e.g. the bel-character, the ff-character,
> the cr-character, the esc-character etc. etc. as a simple identifier,

You could not write just "BEL" in Ada 83, and you still can't in Ada 95.
You have to say "Ascii.BEL;", or you can "use Ascii;" and then you can
say just "BEL".  Same for both Ada 83 and Ada 95.  This is good -- I
don't want my namespace cluttered with all those arcane symbols, most of
which I never use.  Furthermore, the meaning of these control characters
on I/O is rather non-portable, so they shouldn't be directly visible
everywhere.

You cannot say "with Ascii;" -- the name Ascii is always directly
visible (unless you hide it with something else called Ascii).

> the comfort of which will be removed as soon as the
> 'obsolete' package ascii will be removed!

All compilers are required to support package Ascii and all the other
Obsolescent Features.  I doubt if any of the Obsolescent Features will
ever be removed from the language.

> We even cannot write something like character'(bel) or the like.
> Sort of latin1.bel could do it? 

In Ada 95, you can also "with Ada.Characters.Latin_1;", and then say
"Latin_1.BEL", and you can also use a use clause, of course.

> Are there better ideas? Or did I miss a given feature?

You seem to be saying that Ada 95 took something away, which is not
True.  Package Ascii is still there, and still works exactly the same
way.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: obsolete ascii? (for language lawyers)

[Robert Dewar]

In article <7lhqs9$9c$1@infosun2.rus.uni-stuttgart.de>,
  Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote:
> Thanks to John Herro,  David C. Hoos, Sr.,  Ted Dennison.
> I am afraid I did not explain my question precisely enough.
> With Ada95 we have a quite better type character, but
> I can't see any reason why i should not have the possibility
> to directly write down e.g. the bel-character, the
> ff-character,
> the cr-character, the esc-character etc. etc. as a simple
> identifier,
> the comfort of which will be removed as soon as the
> 'obsolete' package ascii will be removed!

Don't worry, there is no possibility whatsoever of anyone
doing anything so idiotic as to create major incompatibilities
by removing package Ascii. Even if the ISO committee did make
a silly decision like this, vendors would put it back.

The whole business of obsolescent features is in my view
completely silly. The features in annex J are so small and
marginal, that to remove them would not begin to be worth
the headaches caused by legacy code.

You should feel free to use any of these features without
the slightest hesitation in my view.


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

Re: obsolete ascii? (for language lawyers)

[Keith Thompson]

Robert Dewar <robert_dewar@my-deja.com> writes:
> Don't worry, there is no possibility whatsoever of anyone
> doing anything so idiotic as to create major incompatibilities
> by removing package Ascii. Even if the ISO committee did make
> a silly decision like this, vendors would put it back.

Agreed.

> The whole business of obsolescent features is in my view
> completely silly. The features in annex J are so small and
> marginal, that to remove them would not begin to be worth
> the headaches caused by legacy code.
> 
> You should feel free to use any of these features without
> the slightest hesitation in my view.

Here, I have to disagree.  Part of the point of declaring a feature to
be obsolescent is to warn that it might be removed in a future version
of the standard.  (I agree that this isn't likely to happen.)  The
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.

I wouldn't use '%' as a string literal delimiter, or write a context
clause for Text_IO (rather than Ada.Text_IO), or a handler for
Numeric_Error, in new code -- not because I expect any of those
features to vanish, but because it's bad style.

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

On the other hand, if you have legacy code that uses these features,
it's not worth going back and changing it unless you're doing a major
rewrite anyway.

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

Re: obsolete ascii? (for language lawyers)

[Robert Dewar]

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.

Re: obsolete ascii? (for language lawyers)

[Keith Thompson]

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.

Re: obsolete ascii? (for language lawyers)

[John Duncan]

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

I have to agree that it's important to have these things remain in the
language, just like it's important to include trigraphs in C++. The point is
that a new version has utility in being an upwardly-compatible superset of
the previous standard. ISO/IEC 646 is more than just a wacky 7-bit set. It
is a character set that the entire world agreed upon as a standard that
could be respected as an acceptable factor of the national languages in use
at the time. It's enough to represent without ambiguity almost all romantic
words, even though it is lacking on punctuation. (You can't do much with 108
characters, considering 52 of them are the basic romantic letters.)

But, provided that strict adherence to the standard is enabled, legacy code
written with trigraphs, which are pretty weird, can be compiled. In the same
way, the however many MSLOC written in standard Ada 83 can be compiled by a
validated Ada 95 compiler. Perhaps you enjoy porting code, but most people
don't. Porting can cause maintenance problems and people get associated to
porting projects that could have been more useful and happy doing
development.

I wonder if you think that COBOL should forgo its column-oriented structure
for a more terminal-friendly one and drop the references to a Hollerith card
completely from the standard. Then, expect people to use the new compilers.
It's absurd. As a new compiler vendor, you'd implement the extensions to
support card format anyway. It's just not worth alienating the old.

-John

Re: obsolete ascii? (for language lawyers)

[Tucker Taft]

Keith Thompson wrote:
> 
> 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.

For what it is worth, I tend to agree with Keith's view more
than Robert's here.  The point of Annex J was to remove from
the main part of the manual the constructs of Ada 83 which were
*perceived by the design team* as being marginal or redundant
in the context of Ada 95.  The goal was to present a (slightly ;-)
simpler language, by moving these marginal/redundant features out
of the main stream of the discussion.  Of course, the manual is
still daunting, and Robert will be happy to point out that the
Ada 83 manual was significantly more readable (warts and all ;-).

But if you want to know the design team's intent, it was along
the lines of what Keith has said -- avoid talking about things that
are only there for supporting legacy code, so that a new user of
Ada encountering the Ada 95 manual has a few less things to worry
about.  Clearly, not all the Ada 9X reviewers had the same perception
of Annex J.

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

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA