From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d1df6bc3799debed
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Not intended for use in medical,
Date: 1997/05/11
Message-ID: <dewar.863323812@merv>#1/1
X-Deja-AN: 240809471
References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com>
 <dewar.862775250@merv> <5kl9qc$g4d@bcrkh13.bnr.ca>
 <5kmek2$9re@bcrkh13.bnr.ca> <E9rMuy.Hs0@world.std.com> <dewar.863062734@merv>
 <33727FA5.5C7A@sprintmail.com> <dewar.863254456@merv>
 <3374C19F.15FE@sprintmail.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-05-11T00:00:00+00:00
List-Id: <comp.lang.ada>


John said

<<Ada.Numerics.Generic_Elementary_Functions?  It can't be because they are
  somehow "intrinsic", because of course intrinsicness can be supplied by
  a pragma.  No, the reason they're all attributes rather than generics is
  because they are extremely convenient to have at the tip of your
  fingers. (I assume that was also the motivation for GNAT's non-standard
  attributes, e.g. X'Img).

Partly that, and partly because they correspond to the generic primitive
functions standard, and also in many cases to the IEEE required operations.

<<The reason for not having included T'Increment etc. could only have been
  either (1) nobody brought up the issue, or (2) well, it was getting
  late, and heck we had to draw the line _somewhere_.  If so, then fair
  enough.>>

No, I think it is just that they seem to junky, at least in this form.
Certainly for instance the notion of "Increment" is inappropriate for
enumeration types. I personally prefer NOT to see T'Increment and
T'Decrement added, and would not find these sufficiently attractive
additions to be worth the extra complexity. So both of the reasons
you guess are wrong -- it is simply that people do not agree with
you that these would have been worth while additions!

<<So why do we have inheritance in Ada95?  Because, quite simply, it was
  perceived by many that Ada9X would be doomed to utter extinction if it
  did not become a fully object-oriented language.>>

This is just wrong, you like to guess about things, but you were not
there, and so it is not surprising that your guesses bear little
relationship to reality.

One of the things that is becoming generally agreed in programming
languages is that you need both genericity (for parametrized abstractions)
and inheritance (for extensible abstractions. Ada 83 had one and not the
other, so providing the other is clearly technically a good idea, and
indeed was in the requirements document for Ada 95. As one of the authors
of that document, I can assure you that the primary motivation for adding
full inheritance in Ada 95 was that we felt there was a strong justifiable
technical need for these features.

Yes, this coincides with political pressures from some quarters, but to think
of these features as being the result of these political pressures is
backwards. The reason for the political pressures was the widespread
technical perception of the importance of extensible abstractions. This
same widespread *technical* perception is what lead to the inclusion of
these features.

<<Case in point: tagged types.  A _huge_ new "gizmo", adding a whole new
  layer of complexity to the language.  It has been argued several times
  (and most recently in an article in the March/April 1997 Ada Letters)
  that tagged type inheritance -- in fact, derived type inheritance in
  general -- compromises one of the original design principles of Ada:
  locality of declaration.>>

Yes, of course these arguments are very familiar, they are the arguments
that were used in excluding general inheritance from Ada 83 in the first
place (remember that the Ada 83 design team was very familiar with object
oriented programming, since they had done extensive programming in
Simula-67 [C++ did NOT invent OO, despite some people's illusions to the
contrary :-)]

However, the fact is that the requirements document rejects these
arguments, as did the majority of those involved with the Ada 9X 
design. Jean Ichbiah strongly supported the addition of OO facilities
to the language in the context of the redesign of the language for
example. Your attempt to create the notion that lots of people opposed
these ideas, but they got put in anyway because of political pressure
simply bares no relation to what actually happened!

<<[*] P.S. Robert, your unconventional quoting style forced me to tease
  out and re-attribute my own words. Doesn't your newsreader/email program
  support good old standard ">" quotations?  You yourself have argued the
  benefits of adhering to widely-established conventions, why make an
  exception here?  (Although I will admit, it does allow me to tell at a
  glance that you are the author of a given post, which I suppose is a
  nice convenience... :-)>>

My environment does not nicely support the > convention for many reasons,
not least of which is that I cannot rewrap things easily. I am following
the quoting suggestion that Norm Cohen made, and I find it solves many
problems

P.S. going back to 'Max and 'Min, I find these tolerable, though unnecessary
additions to Ada 83. If you tell me that your view is that if I have Min
and Max, then I should also have all yoru extra attributes, then I would
prefer to have none of them.