comp.lang.ada
 help / color / mirror / Atom feed
From: bill@valiant (R.A.L Williams)
Subject: Ada self-referential operators
Date: 1 Feb 1995 09:34:35 GMT
Date: 1995-02-01T09:34:35+00:00	[thread overview]
Message-ID: <3gnkjb$gso@miranda.gmrc.gecm.com> (raw)

In article <3g9nir$fpl@gnat.cs.nyu.edu> RobertDewar wrote:
: "The "+=" operator is MADE for this statement, but its ONLY benifit is
: to save me 11 characters in my source file."

: that's going a little far, the purpose of += is much more than saving
: characters, it abstracts the operation to be an increment instead of
: a computation and assignment that just happens to be an increment. 

[long and convincing rationale for += deleted]

: but still I think it is the right choice not to complicate the language to
: add these peculiar forms. Note that in C, where + cannot in any case be
: redefined, they are cleaner, and in algol-68, where parameters are strong
: enough (using ref) to describe variables, they are also cleanly addable.

You seem to be saying that 'because the LRM doesn't have these operators
there is something peculiar about them'. Forgive me if that was not your
intent. 

I'm very much in favour of these concise representations of what the
programmer really intends. I was recently a team leader on a project
(written in C, but that is not really relevant) where, because of constraints
on the target hardware, there was 100% code inspection before attempting
to integrate. Now when you're faced with the quantities of code that
we had and the task of verifying it against design specs and Yourdon
analysis (the design methodology retained p-specs into the coding stages
as design information) then you *really* appreciate every labour saving
device that the coder can introduce!

: Often in a lanuage there are things that would be nice but don't fit very 
: well. If nice is *very* nice, then sometimes we are willing to accept a
: complex wart in the language, but if nice is only a *little* nice, it's
: better to opt for cleanliness, and this is such a case I think in Ada 95.

So far as I can see, the main reason that allowing "+=" etc. to be
overloaded does not fit in with the rest of Ada is that ":=" cannot
be overloaded. Well, this again is an unfortunate oversight. In linear
algebra packages, for example, it is frequently desirable to have
an implicit garbage collection mechanism for temporary results. The
assignment operator is a good place to put this. In C++ the overloaded
assignment operator is often used to implement constraint checking.
While this is not as valuable in Ada, I know of at least one military
C3I system where a particular type, TX frequency, must be constrained
into three non-contiguous bands. This would be hard to represent
without an explicit test in Ada. (Since most of the code for that
particular system was originally written in Fortran I suppose the
issue never arose!)

Admittedly, the situation in C++ is different from Ada. In C++ every
expression has a value, and an assignment counts as an expression. It 
is therefore logical to allow overloading the assignment operator
as a function. In Ada, OTOH, ":=" would need to be overloaded by a
procedure, making it unique amongst the 'predefined operators'. I don't
see any other reason why this is not a 'clean' extension. Perhaps
":=" wouldn't stick out so much if it had "+=" etc. to keep it company?

Still, I suppose we must accept the consensus view on Ada9x. Perhaps
in Ada0x....?

Bill Williams



             reply	other threads:[~1995-02-01  9:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-02-01  9:34 R.A.L Williams [this message]
     [not found] ` <3hnoe6$1aoi@info4.rus.uni-stuttgart.de>
     [not found] ` <3grqrf$jkd@gnat.cs.nyu.edu>
1995-02-06 20:51   ` Ada self-referential operators Kenneth Almquist
1995-02-08  2:06     ` John Volan
1995-02-08  6:45       ` Jay Martin
1995-02-08  9:04       ` Brian Rogoff
1995-02-08 20:13         ` John DiCamillo
1995-02-09 23:52           ` David Weller
1995-02-10  6:48         ` pang
1995-02-10 16:15           ` Robert I. Eachus
1995-02-09 17:30       ` Norman H. Cohen
1995-02-11 13:56         ` Robert Dewar
     [not found]   ` <3id9qi$a7m@usenet.srv.cis.pitt.edu>
1995-02-25 13:28     ` Larry Kilgallen, LJK Software
1995-03-08 23:26     ` Val Kartchner
  -- strict thread matches above, loose matches on Subject: below --
1995-02-10 17:07 R.A.L Williams
1995-02-11  5:34 ` Keith Thompson
     [not found] <3id0oo$e64@gnat.cs.nyu.edu>
1995-02-23 17:45 ` Brian Hanson
1995-03-01 18:41   ` Thomas G. Coles (1W0)
replies disabled

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