Re: Not intended for use in medical,

["John G. Volan" <johnvolan@sprintmail.com>]

I (John Volan) wrote: [*]
>
> 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.

Robert Dewar replied: [*]
>
> 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.

John Volan replies:

I will grant you that a language feature cannot be justified _solely_ on
political grounds, it has to have enough utility in its own right to
outweigh the cost of the added complexity.  In this case, however, I
believe T'Increment and so forth _would_ have had merit in their own
right, irrespective of any analogy they might bear to C++ side-effect
operators.  As I pointed out, they'd help avoid unnecessary and
error-prone repetition of variable names in certain common cases of
arithmetic statement, and I believe they'd thereby enhance readability.

> Every time I have seen this done I think it is a mistake. Three
> examples:
[snip good examples of bad language compromises]

In each of these cases, a general design principle in language X was
compromised to introduce a specific exceptional case, with the only
justification being that it was politically necessary to make that
special case resemble language Y.

But I don't see how any of these are an analogy to T'Increment, etc. 
How would these be special exceptional cases of attributes?  I don't see
how they'd "compromise" any of Ada's design principles at all.

Now, if I had suggested that these be _functions_ that caused side
effects but also returned values or (shudder, shudder) returned
"references" to variables, then that truly would have "compromised"
Ada's design.  Likewise if I had suggested, as others have, that we
introduce new side-effect delimiters, e.g. "+:=", "-:=", "*:=" etc.  But
I suggested nothing of the sort.

In fact, these attribute procedures would be no different in kind from
any other attribute subprogram already present in Ada95.

Consider T'Min and T'Max.  Why were they added, when their functionality
could easily have been supplied with a generic? In fact, it could have
been just another generic child of package Ada.  Why aren't T'Ceiling,
T'Floor, and the like just more functions in
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).

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.

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

I agree, but having said all that, you can't _entirely_ ignore politics
when designing a language, not it today's climate.  And in fact, the
design of Ada95 certainly did not (_could_ not) ignore politics.

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.  If a package declares a derived type, you
cannot simply look at that package and know what record components and
primitive subprograms are defined for that type.  You also have to hunt
down the package that declares the base type, and look at its components
and primitives. If that base type was derived from something else, you
have to hunt down _that_ package too, and so on.  And if you do
classwide programming and get dynamic dispatching, then it's no longer
true that you can just look at a subprogram call and know exactly what
code is getting invoked.  All of these things, if abused, can be
detrimental to the goals of software engineering and real-time embedded
programming. 

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.  Large constituencies
in the computer industry would simply reject it out of hand.  (_I_ would
have rejected it, and if you know me, that's saying a lot.)  Now, at
least, Ada95 stands a fighting chance.  Isn't it obvious that the
decision to add type extension and OO-style inheritance was at least
_partly_ political?

[*] 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... :-)

------------------------------------------------------------------------
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? :-) ");
------------------------------------------------------------------------