Re: Language Design Mistakes (was "not intended...")

Re: Language Design Mistakes (was "not intended...")

[John Herro]

bobduff@world.std.com (Robert A Duff) writes:
> There was some push for Ada 9X to allow
> anonymous arrays for record components...

It might be surprising, but that was allowed in the 1980 Ada
standard!  (It was, of course, removed in Ada 83).

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

Re: Language Design Mistakes (was "not intended...")

[David Emery]

My favorite Ada80 feature that "didn't make the cut" into Ada83 
was "generic tasks"...

				dave
-- 
Note: if email to me bounces, use 'emery@grebyn.com'

Re: Language Design Mistakes (was "not intended...")

[John Herro]

I wrote:
>> It might be surprising, but that was allowed in the 1980 Ada
>> standard!  (It was, of course, removed in Ada 83).
Robert Dewar wrote:
> ... there was no such thing as "the 1980 Ada standard"...
> There were ... preliminary drafts ... and it is perhaps to
> one of these that John refers.

I was referring to ANSI/MIL-STD-1815, without the "A."

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

Re: Language Design Mistakes (was "not intended...")

[Jeff Carter]

John Herro wrote:
> 
> I wrote:
> >> It might be surprising, but that was allowed in the 1980 Ada
> >> standard!  (It was, of course, removed in Ada 83).
> Robert Dewar wrote:
> > ... there was no such thing as "the 1980 Ada standard"...
> > There were ... preliminary drafts ... and it is perhaps to
> > one of these that John refers.
> 
> I was referring to ANSI/MIL-STD-1815, without the "A."
> 
> - John Herro
> Software Innovations Technology
> http://members.aol.com/AdaTutor
> ftp://members.aol.com/AdaTutor

I think that was only MIL-STD-1815, dated 1980 Dec, not an ANSI
standard.
-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Language Design Mistakes (was "not intended...")

[John Herro]

Jeff Carter <carter@spam.innocon.com> writes:
> I think that was only MIL-STD-1815, dated 1980 Dec,
> not an ANSI standard.

I think you're right.  I was relying on my memory (not too reliable!),
because I have only the Ada 83 and Ada 95 standards with me.  I'm
sure I threw out my old copy of MIL-STD-1815.

I remember that MIL-STD-1815 had subtype NATURAL defined as
what is now subtype Positive, and it had no subtype POSITIVE at
all.  Also, of course, it allowed anonymous arrays for record
components.  There were some other differences with Ada 83,
which I don't recall at the moment.

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

Re: Language Design Mistakes (was "not intended...")

[W. Wesley Groleau (Wes)]

Robert Dewar wrote:
> John Herro says
> <<It might be surprising, but that was allowed in the 1980 Ada
> standard!  (It was, of course, removed in Ada 83).>>
> 
> It is indeed surprising given that there was no such thing as "the
> 1980 Ada standard". The first standard for Ada was in April of 1993.
> ....

Before we start a semantic war about the definition of "standard"
let me point out that I have a copy of MIL-STD-1815A (1983) where 
the STD (rightly or wrongly) means "standard"  In fact, before 
I read the quote above, I was planning to post the following query 
(for unrelated reasons):

  Anyone know of an online source for MIL-STD-1815, or whether
  (and where) the "assert" statement can be found in a
  (semi-)official pre-1983 Ada publication (online OR printed)?

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Language Design Mistakes (was "not intended...")

[Mark Hertel]

"W. Wesley Groleau (Wes)" <see.signature@this.message> writes:

> Robert Dewar wrote:
> > John Herro says
> > <<It might be surprising, but that was allowed in the 1980 Ada
> > standard!  (It was, of course, removed in Ada 83).>>
> > 
> > It is indeed surprising given that there was no such thing as "the
> > 1980 Ada standard". The first standard for Ada was in April of 1993.
> > ....
> 
> Before we start a semantic war about the definition of "standard"
> let me point out that I have a copy of MIL-STD-1815A (1983) where 
> the STD (rightly or wrongly) means "standard"  In fact, before 
> I read the quote above, I was planning to post the following query 
> (for unrelated reasons):

The full title is ANSI/MIL-STD-1815A-1983, but there were two "official"
Language Reference Manuals released in 1980, in July and November. The
book I have refers to an ANSI study conducted in 1981 that led to some
changes and produced the ANSI/MIL-STD-1815A, dated February 17, 1983.

The "A" represents a change to the MIL-STD-1815 which was the 1980
military standard but not an ANSI standard.

Mark Hertel

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

Re: Language Design Mistakes (was "not intended...")

[hamilt2d]

>    Anyone know of an online source for MIL-STD-1815, or whether
>    (and where) the "assert" statement can be found in a
>    (semi-)official pre-1983 Ada publication (online OR printed)?
>  
An example of an assert statement is found on page 31 of the Red Language Reference Manual dated March 1979
and a definition of an assert statement is found on page 5 - 10 of the Green Language Reference Manual dated March 1979.
These are not "official" in the DOD sense of the word.  As Bob Duff indicated, both manuals are interesting reading -- particularly 
the names listed in the acknowledgements.  

Regards,

Drew Hamilton 

Re: Language Design Mistakes (was "not intended...")

[Samuel A. Mize]

For those of us with historical interest, are there available:
- MIL-STD-1815
- Red language manual
- Green language manual
- any other color manual (I don't recall -- weren't there three?)

If these are only available on paper, I'll pay for copying and
postage, and then make copies available for copying cost (if
copyright allows, of course).

Thanks,
Sam Mize

hamilt2d@ncr.disa.mil wrote:
> 
> >    Anyone know of an online source for MIL-STD-1815, or whether
> >    (and where) the "assert" statement can be found in a
> >    (semi-)official pre-1983 Ada publication (online OR printed)?
> >
> An example of an assert statement is found on page 31 of the Red
>Language Reference Manual dated March 1979
> and a definition of an assert statement is found on page 5 - 10 of
>the Green Language Reference Manual dated March 1979.
> These are not "official" in the DOD sense of the word.  As Bob Duff
>indicated, both manuals are interesting reading -- particularly
> the names listed in the acknowledgements.
> 
> Regards,
> 
> Drew Hamilton

--
-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: Language Design Mistakes (was "not intended...")

[Robert A Duff]

In article <199705151433.OAA18453@sw-eng.falls-church.va.us>,
John Walker  <walkerj@SW-ENG.FALLS-CHURCH.VA.US> wrote:
>It is not at all clear that MIL-STD-1815 was merely a "draft" for
>1815A.  I have heard both that the differences between the two
>versions were profound and crucial, *and* that they were relatively
>modest.

I have a copy of the Ada manual from July 1980.  From the point of view
of a programmer, the changes from this document to the final Ada 83
standard were modest -- the bulk of the functionality, and what it
looked like, didn't change much.  However, lots of bugs were fixed, and
other minor changes were made.  To a compiler writer, these changes are
quite large.  Here are a couple of the "bigger" changes (from both
points of view):

In Ada 80, you could say "raise T'Failure;", for any task T.  This was a
lot like "abort T;", except that T could handle it (using an exception
handler).  This feature has a lot in common with Ada 95's "select...then
abort...".

Ada 80 required the compiler to determine a "correct" elaboration order,
by looking at which subprograms get called (directly and indirectly)
during elaboration, and making sure the bodies of those subprograms are
elaborated before the calls.  One way to read this rule requires the
compiler to predict (at link time) which calls will happen during
elaboration (at run time).  This is of course ludicrous, since it would
require the compiler/binder to (1) solve the halting problem, and (2) predict
the value of any input data read during elaboration.  Therefore, I
*suspect* that they meant for the compiler/binder to do a walk of the
call graph.  This rule was eliminated for Ada 83, and pragma Elaborate
was added.

Here's a "smaller" change: There was a rule that you couldn't have a
record component that is an array with non-static bounds, *unless* those
bounds are discriminants.  This rule was eliminated between 1980 and
1983.

>...It might be interesting from a historical perspective for
>someone to describe the differences and their signficance, both for
>the language and for its implementation.  If anyone is aware of any
>publications on the topic, I'd really like to hear about them.

Well, if you can get ahold of it, the best thing to do is read the old
document(s), instead of somebody's list of differences.

The differences between Green and Ada 83 are much larger, and more
interesting.  E.g. the entire tasking model was completely redone.

Another interesting thing to do is to read the Red manual.

- Bob

Re: Language Design Mistakes (was "not intended...")

[Robert Dewar]

Bob Duff said

<<In Ada 80, you could say "raise T'Failure;", for any task T.  This was a
lot like "abort T;", except that T could handle it (using an exception
handler).  This feature has a lot in common with Ada 95's "select...then
abort...".>>

And one of the reasons that it was rejected was that it was impossible
to implement without a lot of distributed overhead.

The Ada 95 select .. then abort ... also introduces the same kind of
distributed overhead, but this time around, this overhead did not seem
to bother people (somewhat inexplicably if you ask me -- this is my least
favorite feature of Ada 95 -- and we have noticed repeatedly that people
use this construct without any idea of what the consequences are, not only
on efficiency, but more particularly on program structure, and they are easily
argued out of using it!)

Re: Language Design Mistakes (was "not intended...")

[Robert I. Eachus]

In article <dewar.863817572@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > The Ada 95 select .. then abort ... also introduces the same kind
  > of distributed overhead, but this time around, this overhead did
  > not seem to bother people (somewhat inexplicably if you ask me --
  > this is my least favorite feature of Ada 95 -- and we have noticed
  > repeatedly that people use this construct without any idea of what
  > the consequences are, not only on efficiency, but more
  > particularly on program structure, and they are easily argued out
  > of using it!)

    T'FAILURE and "select ... then abort" both try to provide for the
same need.  However, no one could come up with a working example of code
that used T'FAILURE.  That is what washed it out of Ada 83.  But the
need was still there in 1993.

    Incidently, I am not convinced that there is any additional
overhead attached to asynchronous abort that isn't there for the
"normal" abort statement.  It is just that the asynchronous abort
stucture convinces people to actually use the beast in something other
than a crowbar through the flywheel role.

--

					Robert I. Eachus

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

Re: Language Design Mistakes (was "not intended...")

[Juanma Barranquero]

On Fri, 16 May 1997 19:38:12 GMT, bobduff@world.std.com (Robert A
Duff) talked about:

>The differences between Green and Ada 83 are much larger, and more
>interesting.  E.g. the entire tasking model was completely redone.
>
>Another interesting thing to do is to read the Red manual.

Where can be found the Green & Red manuals/specifications? I've been
wanting (just out of curiosity) to see what Red was like, but I've
been unable to find any on-line document about it...

Thanks,

-- 
						  /L/e/k/t/u

Re: Language Design Mistakes (was "not intended...")

[Robert Dewar]

John Walker said

<<It is not at all clear that MIL-STD-1815 was merely a "draft" for
1815A.  I have heard both that the differences between the two
versions were profound and crucial, *and* that they were relatively
modest.>>

Both are true. There are changes that from a fundamental semantic point
of view are quite significant, and in fact that corrected major errors
that caused significant semantic problems, and significant implementation
problems (remember that at NYU we implemented the 79 and 80 drafts, or
tried to, as well as implementing the final standard). On the other hand,
the changes from a users point of view were indeed relatively modest.

The 1980 MIL standard was indeed a draft. No one implemented it, nor could
it have been successfully and completely implemented, given some significant
semantic problems.

Re: Language Design Mistakes (was "not intended...")

[John Walker]

On Thu, 15 May 1997 14:02:54 GMT, "W. Wesley Groleau (Wes)"
writes:

>let me point out that I have a copy of MIL-STD-1815A (1983) where
>the STD (rightly or wrongly) means "standard"  In fact, before
>I read the quote above, I was planning to post the following query
>(for unrelated reasons):
>
>  Anyone know of an online source for MIL-STD-1815, or whether
>  (and where) the "assert" statement can be found in a
>  (semi-)official pre-1983 Ada publication (online OR printed)?

Well, since we're being precise about terms, and since the
context makes this a report of an abandoned intention, maybe
I don't need to reply. :) :)

However:

I'm not aware of any electronic copy of MIL-STD-1815 (unlike
1815A, which is available on the sw-eng site).  If anyone
else is aware of an electronic copy of 1815, I'd appreciate
hearing about it.)

I have a paper copy, however, I don't find the word assert as
such in the index nor in a quick scan of the syntax summary.

take care,

John
         ---------------------------------------------------
           John Walker, walkerj@sw-eng.falls-church.va.us
              ---Assembler is a high-level language.---
 .GET DSCLAIMR.STD   ; & consider the effect of the insertion point
         ---------------------------------------------------

Not intended for use in medical,

[Robert C. Leif, Ph.D.]

To: Tim Behrendsen, Kaz Kylheku et al.
From: Robert C. Leif, Ph.D.
Vice President Ada_Med

The quote," Intel products are not intended for use in medical, life
saving, or life sustaining applications."  as you stated is in Pentium
Processor Specification Update_ from Intel, January 1997.   I called Intel.
The document can be ordered at 800.548.4725.  Intel said that there was no
charge.  The National 32 bit processor had a similar disclaimer.  Do you or
any of the other readers of Comp.Lang.Ada know of other similar
disclaimers?  Many medical instruments use  Intel  486 and Pentium devices.

This quote may provide an excellent opportunity in the medical device
business, which is NOT puny.  My question is, Does validation of an Ada
compiler on a platform provide significant evidence that the processor
produces valid object code?  Would any of the other Ada test suites help?
I deliberately used the word significant rather than sufficient.  If anyone
knows how to prove sufficiency, I would also like a comment.  Any other
suggestions that would permit realistic development of medical devices
would be appreciated.

Microsoft would be well advised to include this type of disclaimer.
Actually, Bill Gates would be best advised to suggest that medical device
manufacturers purchase Ada compilers.  Microsoft is a product liability
lawyer's dream come true, real deep pockets.  Many medical devices are
hosted on Windows and Windows NT Intel computers. Macintoshes are also used.

Although the lawyers are of interest, the response of the FDA will be more
interesting.
You wrote
----------------------------------------------------------------
Date:    Fri, 18 Apr 1997 14:18:41 GMT
From:    Tim Behrendsen <tim@A-SIS.COM>
Subject: Re: Any research putting c above ada?

Kaz Kylheku <kaz@vision.crest.nt.com> wrote in article
<5j5kqf$adm@bcrkh13.bnr.ca>...

> Consider this:
SNIP
>     Intel products are not intended for use in medical, life saving, or
>     life sustaining applications.
>
> This quote is taken from _Pentium Processor Specification Update_ from
Intel,
> January 1997. It is in the very first disclaimer paragraph on the inside
> front  cover.

The reason is probably that the medical market is so puny that they
figured it wasn't worth being dragged into a lawsuit if a medical
manufacturer was sued.  That sounds like lawyer-speak to me.
----------------------------------------------------------------------------
-----------

Re: Not intended for use in medical,

[Robert Dewar]

Kaz said

<<Sorry about this C intrusion into comp.lang.ada. I didn't intend that
  example to spark a discussion about C semantics, but just to clear up,
  the && operator in C has sequencing properties. Its left constituent
  must not only be evaluated before its right, but its side effects must
  also be settled before the left side is evaluated. Hence   x++ && x++  is
  perfectly well defined. The program I was writing depended on this crucial
  sequencing property.>>

  Yes, legal, but horrible. A good reminder of why Ada does NOT have
  the ++ operator built in :-)

<<The complexity was hidden behind friendly macros. :)>>

  How can it ever be friendly to hide a ++ in a macro, such that the
  peculiar rules about not using more than one ++ in an expression
  suddenly apply in a hidden manner to the macro, Ugh!

Re: Not intended for use in medical,

[Kaz Kylheku]

In article <dewar.862775250@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Kaz said
>
><<Sorry about this C intrusion into comp.lang.ada. I didn't intend that
>  example to spark a discussion about C semantics, but just to clear up,
>  the && operator in C has sequencing properties. Its left constituent
>  must not only be evaluated before its right, but its side effects must
>  also be settled before the left side is evaluated. Hence   x++ && x++  is
>  perfectly well defined. The program I was writing depended on this crucial
>  sequencing property.>>
>
>  Yes, legal, but horrible. A good reminder of why Ada does NOT have
>  the ++ operator built in :-)
>
><<The complexity was hidden behind friendly macros. :)>>
>
>  How can it ever be friendly to hide a ++ in a macro, such that the
>  peculiar rules about not using more than one ++ in an expression
>  suddenly apply in a hidden manner to the macro, Ugh!

How can it ever be friendly? If you take care to use proper sequencing
operations to protect the user from the side effects, as I did. Thus the
``peculiar rules'' were taken care of. In my original macro, the quantities
that were compared and incremented were structure members. The only caveat was
that the pointer to the structure was evaluated more than once by the macro
(the same way that getc() or putc() possibly evaluate the FILE * pointer
argument more than once). In any case, these macros were for internal use.

There is a more serious snag: if someone naively did something silly like foo()
+ foo(), undefined behavior could result. Even though both constituents of the
+ contain the && sequencing operator, the + operator doesn't guarantee a
particular order of evaluation. The sequence points in both constituents are
independent, so that

    ((x < y) && x++) + ((x < y) && x++)

could, in the actual semantics, evaluate both constituents in an interleaved
fashion, perhaps even effectively merging the sequence points into one.

God I love this stuff! :)

Re: Not intended for use in medical,

[Kaz Kylheku]

In article <5kl9qc$g4d@bcrkh13.bnr.ca>,
Kaz Kylheku <kaz@vision.crest.nt.com> wrote:
>In article <dewar.862775250@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>>Kaz said
>>
>><<Sorry about this C intrusion into comp.lang.ada. I didn't intend that
>>  example to spark a discussion about C semantics, but just to clear up,
>>  the && operator in C has sequencing properties. Its left constituent
>>  must not only be evaluated before its right, but its side effects must
>>  also be settled before the left side is evaluated. Hence   x++ && x++  is
>>  perfectly well defined. The program I was writing depended on this crucial
>>  sequencing property.>>
>>
>>  Yes, legal, but horrible. A good reminder of why Ada does NOT have
>>  the ++ operator built in :-)

By the way, the x++ is just another way of writing the assignment expression x
+= 1, or x = x + 1 (the latter case evaluates x twice, of course).  The real
``evil'' perhaps is that in C an assignment is an expression rather than a
statement, so that you can decorate a complex expression with assignments all
over the place.

Note that this is one of the areas of C which C++ _worsens_ significantly.
In C++, the result of an assignment expression is not only an expression
itself, but it is also an _lvalue_. Talk about lunacy.

With one stroke, the C++ ``designers'' introduce a whole new batch of nonsense,
such as 

    (i = x) = y;

which must be rejected by any conforming C implementation as constraint
violation. 

What's the final value of i? Is it x? Or is it y?
My friend, do not waste your time: the behavior's undefined.

Better C indeed! :)

Re: Not intended for use in medical,

[Robert A Duff]

In article <5kmek2$9re@bcrkh13.bnr.ca>,
Kaz Kylheku <kaz@vision.crest.nt.com> wrote:
>>>  Yes, legal, but horrible. A good reminder of why Ada does NOT have
>>>  the ++ operator built in :-)
>
>By the way, the x++ is just another way of writing the assignment expression x
>+= 1, or x = x + 1 (the latter case evaluates x twice, of course).  The real
>``evil'' perhaps is that in C an assignment is an expression rather than a
>statement, so that you can decorate a complex expression with assignments all
>over the place.

I agree (except I'd remove "perhaps").  There's nothing wrong with
having short-hand notations like "++" and "+=".  The language design
flaw in C is that assignments return something "useful", thus
encouraging side effects nested within expressions, like a[i++].
I'm not against *all* kinds of side effects, but I'm against most of
them, including the one mentioned above.

- Bob

Re: Not intended for use in medical,

[Robert Dewar]

Robert Duff said

<<I agree (except I'd remove "perhaps").  There's nothing wrong with
having short-hand notations like "++" and "+=".>>

There is something potentially wrong, which is that compact operation
notations like this are most happy with short identifier names, as in

   a++;

not nearly so pretty is

   Average_Daily_Rate_Of_Pay++;

and indeed if you speak the above, it comes out as a joke, people laugh.

Well of course this is not the only reason that C programmers so often
favor short cryptic identifier names (and of course there is nothing in C
which requires them), but it is a contributing factor!

Re: Not intended for use in medical,

[John G. Volan]

Robert Dewar wrote:
> 
> Robert Duff said
> 
> <<I agree (except I'd remove "perhaps").  There's nothing wrong with
> having short-hand notations like "++" and "+=".>>
> 
> There is something potentially wrong, which is that compact operation
> notations like this are most happy with short identifier names, as in
> 
>    a++;
> 
> not nearly so pretty is
> 
>    Average_Daily_Rate_Of_Pay++;
> 
> and indeed if you speak the above, it comes out as a joke, people laugh.

That's why I've suggested before that an Ada analog to "++" could have
been rendered as a procedure attribute:

    Money_Type'Increment (Average_Daily_Rate_Of_Pay);

Far less error prone than:

    Average_Daily_Rate_Of_Pay :=
      Average_Weekly_Rate_Of_Pay + 1;  -- Oops! Ah, if only ... :-) 

I mean, if T'Min and T'Max could make it into Ada95, then why not:

    procedure T'Increment (X : in out T);            -- ++ analog
    procedure T'Decrement (X : in out T);            -- -- analog
    procedure T'Increase  (X : in out T; By : in T); -- += analog
    procedure T'Decrease  (X : in out T; By : in T); -- -= analog
    procedure T'Multiply  (X : in out T; By : in T); -- *= analog
    procedure T'Divide    (X : in out T; By : in T); -- /= analog

Yes, I know these can all be done with ordinary procedures and generics,
and I know there's a limit to what you can cram into a language
specification. But in this case, I think it would have been politically
savvy to have included something like these attributes, as an answer to
the challenge from C++'s operators.

Well, we've been down this road before. What was that about "wishes and
fishes" ...? :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Not intended for use in medical,

[Robert Dewar]

<<Yes, I know these can all be done with ordinary procedures and generics,
and I know there's a limit to what you can cram into a language
specification. But in this case, I think it would have been politically
savvy to have included something like these attributes, as an answer to
the challenge from C++'s operators.>>

Bad reason! It is almost always a mistake in languages to make compromises
in the design on the grounds that users of language X won't be happy unless
you do. Every time I have seen this done I think it is a mistake. Three
examples:

In Algol-68

  Really we should make people write ref all the time because it is important
  for people to know that something is a variable, but if we make the normal
  declaration for an integer variable be:

     ref int x;

  Fortran and Algol-60 programmers will never tolerate it, so let's make
  a special rule -- that the ref is implied here, so we can write:

     int x;

  but only in this case, for other declaration forms, the ref is required.

  Bottom line: confusion, and surprise! Neither Algol-60 nor Fortran
  programmers like confusion!

In Ada 83 (and Ada 95)

  Really we should declare the type of everything, but Fortran users would
  never put up with

      for x in integer range 0 .. 10 loop ...

  so let's have a special rule that we get a default use of integer here.

  Similarly, Fortran users will never put up with having to declare all
  those array types, so let's allow anonymous array declarations:

  My opinion is that both these decisions are mistakes, they introduce
  irregularity and confusion.

People are not going to say, "Hey, let's use Ada because it has all the
goodies we know and love from language X". If that is their viewpoint,
there is a language that much more certainly has all the goodies from
language X, and that they are much more likely to use.

If people switch to a new language it is because they see some general
advantages. If they make the switch, they want to find something coherent
and well designed when they get there.

Features should go in a language because they make sense in terms of the
syntactic and semantic framework of the language, not because of some
perceived political value. That is especially true of tiny syntactic
gizmos.

Language Design Mistakes (was "not intended...")

[W. Wesley Groleau (Wes)]

Robert Dewar wrote:
>   Similarly, Fortran users will never put up with having to declare 
>   all those array types, so let's allow anonymous array declarations:
> 
>   My opinion is that both these decisions are mistakes, they introduce
>   irregularity and confusion.

As Robert said, making a design decision to placate a Fortran user is
a mistake.  But there is a place for arrays of anonymous types.

If there is no conceivable reason for ever passing the value of an
array to a subprogram or entry, or assigning to or from the array
or a slice of it, then it will always be the only array of its type,
so a superfluous type declaration is merely clutter _hindering_
source readability.  (Some say the type name can be chosen for 
documentation value, but I don't see why that can't all go into
the object name.)

Since arrays that do not meet the above "uniqueness test" are quite
awkward to handle anonymously (due to "strong typing"), there is no 
need for rigid "thou shalt never use an anonymous array type" rules.
I have viewed a lot of code in my career, and I'm not just speculating
when I call a superfluous type declaration "detracting clutter."
(BTW, if an array type has only one instance, but additional variable/
parameter instances are "conceivable," then I do not take the above
viewpoint.)

* The rest of Robert's post I agreed with.

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Language Design Mistakes (was "not intended...")

[Robert Dewar]

Wes said

<<If there is no conceivable reason for ever passing the value of an
array to a subprogram or entry, or assigning to or from the array
or a slice of it, then it will always be the only array of its type,
so a superfluous type declaration is merely clutter _hindering_
source readability.  (Some say the type name can be chosen for
documentation value, but I don't see why that can't all go into
the object name.)>>

OK, but just make sure you know the rules. If you think this way, it is
all too easy to expect this to extend to a protected object that protects
an array, this is a very common syntactic error. Or that it extends to
a single field of a record that appears only once.

Re: Language Design Mistakes (was "not intended...")

[W. Wesley Groleau (Wes)]

Robert Dewar wrote:
> 
> Wes said
> 
> <<If there is no conceivable reason for ever passing the value of an
> array to a subprogram or entry, or assigning to or from the array
> or a slice of it, then it will always be the only array of its type,
> so a superfluous type declaration is merely clutter _hindering_
> source readability.  (Some say the type name can be chosen for
> documentation value, but I don't see why that can't all go into
> the object name.)>>
> 
> OK, but just make sure you know the rules. If you think this way, it is
> all too easy to expect this to extend to a protected object that protects
> an array, this is a very common syntactic error. Or that it extends to
> a single field of a record that appears only once.

I am aware of those rules, but even if I was not, the compiler would
enforce them.  Hence, there is still no need for a coding standard
that people can use to "substitute for judgment."

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Language Design Mistakes (was "not intended...")

[Robert A Duff]

In article <dewar.863496826@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Wes said
>
><<If there is no conceivable reason for ever passing the value of an
>array to a subprogram or entry, or assigning to or from the array
>or a slice of it, then it will always be the only array of its type,
>so a superfluous type declaration is merely clutter _hindering_
>source readability.  (Some say the type name can be chosen for
>documentation value, but I don't see why that can't all go into
>the object name.)>>

This is true, but if the language is going to allow this for arrays and
tasks, it should allow it for all types.  That would make the language
simpler, by making it more uniform.  It might even be useful, once in a
while:

    Recursion_Count: range 0..100 := 0; -- "range 0..100" declares an
                                        -- anonymous integer type.
                                        -- This isn't Ada.
    
    function F(...) return ... is
    begin
        Recursion_Count := Recursion_Count + 1; -- Blow up if runaway recursion
        ... F(...) ...
        Recursion_Count := Recursion_Count - 1;
    end F;

This is better than having a named type, for the reasons stated by Wes,
above.  And it's better than using an existing type, such as Integer,
because it clearly expresses the fact that Recursion_Count isn't being
freely mixed with any other integer variables, which is a useful fact
when understanding the program.

Note that protected types (originally called protected *records*) can be
anonymous, making them uniform with tasks, but not with records.

>OK, but just make sure you know the rules. If you think this way, it is
>all too easy to expect this to extend to a protected object that protects
>an array, this is a very common syntactic error. Or that it extends to
>a single field of a record that appears only once.

There was some push for Ada 9X to allow anonymous arrays for record
components and the like, for uniformity, but it adds complexity, and so
we decided it wasn't worth it.  Where does that anon array type get
implicitly declared?  Certainly not just before the component_decl
(which would be analogous to the object_decl case), because that would
result in nested types, which cause semantic trouble.  Certainly not
just before the record type decl, because then you couldn't make the
bounds depend on discriminants, which would be an unexpected
non-uniformity.  Maybe the array type gets implicitly declared before
the record, and its first subtype before the component?

- Bob

Re: Language Design Mistakes (was "not intended...")

[Robert Dewar]

Bob Duff said

<<This is true, but if the language is going to allow this for arrays and
tasks, it should allow it for all types.  That would make the language
simpler, by making it more uniform.  It might even be useful, once in a
while:>>

My example here would be

  System_Status : (Going, Stopped, Terminating);

but allowing anonymous types uniformly, as Bob Duff said, would lead to
a huge increase in complexity for relatively little gain (Even thinking
about implementing it in GNAT makes my head ache :-)