comp.lang.ada
 help / color / mirror / Atom feed
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Type extension with GNAT
Date: 23 Feb 95 23:32:09 GMT
Date: 1995-02-23T23:32:09+00:00	[thread overview]
Message-ID: <EACHUS.95Feb23183209@spectre.mitre.org> (raw)
In-Reply-To: dewar@cs.nyu.edu's message of 22 Feb 1995 22:14:03 -0500

In article <3iguhr$ai4@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

  > I disagree with Robert Eachus' complaint about overloading and
  > overriding.  The critical point here is that constructors of this
  > type should not be made primitive. THAT's the solution, and that's
  > what we shold teach people to understand.

   If the fact that users need to put constructors in nested packages
is the worst feature of Ada 95, then everyone involved did an
incredibly good job. (And even if there are a few other worse
blemishes discovered, Ada 95 turned out to be fantastically better
than we could have hoped when the process started.)  But given the
amount of traffic generated on the net, and the number of times I have
already had to explain this "feature" to naive users, I am going to
grow very, very tired of explaining this over the next decade.

   Hmmm, maybe I had better explain where I am coming from.  There was
obviously a lot that could be improved in Ada 83, but there were some
cases where judgement calls had to be made.  In some cases the choices
made were right for the time, but needed to be revisited in the
revision.  In many other cases history proved the decisions right.
But there were two decisions which obviously hurt the acceptance of
the language.

   I'm not sure, even in hindsight, whether the choice to leave the
elementary math functions out of Ada 83 was right or wrong.  (For Ada
9X, leaving them out was almost unthinkable--but that reflected the
results of lots of work by many dedicated people.  And the decision in
82 was that the work couldn't be done in time for that version of the
standard, and putting in a poorly specified package would have been a
mistake.  Fair enough.)

   But I have ALWAYS felt guilty about the wording in the manual on
expiration of delays.  I feel that I correctly pointed out to the
design team that the previous wording had unimplementable
requirements, but I should have realized how the proposed correction
would be read by non-language lawyers. (Robert Dewar should probably
feel some guilt as well, for pointing out publicly--and
correctly--that implementations without multple priority levels could
be more useless than most people thought.)  As the RM is written, if a
compiler supports more than one priority level, it must do expiration
of delays correctly.  However, the wording seems to say that compilers can
be lazy about restarting tasks after a delay, and this became a common
misperception about Ada in embedded programming circles.

   Now I don't feel any guilt associated with the derivation of
constructors in Ada 95.  Even if in ten years we discover a better
approach, that doesn't make the current design wrong.  But I intend to
work as hard as I can to make this a known design rule that gets into
all the style guides and all the textbooks, so that we don't lose
potential Ada users over this extremely minor seeming issue.
--

					Robert I. Eachus

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



  parent reply	other threads:[~1995-02-23 23:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3ib6h2$19q4@source.asset.com>
     [not found] ` <EACHUS.95Feb21141055@spectre.mitre.org>
1995-02-23  3:14   ` Type extension with GNAT Robert Dewar
1995-02-23 14:59     ` Cyrille Comar
1995-02-23 16:31       ` Robert Dewar
1995-02-28 17:00       ` David Wheeler
1995-02-23 23:32     ` Robert I. Eachus [this message]
1995-03-19 22:04   ` "Jim Wall"
1995-03-13 22:22 Michael M. Bishop
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox