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

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

[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 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...")

[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]

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

[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 :-)

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

[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...")

[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...")

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

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

[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...")

[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