+= in ada

+= in ada

[Dmytry Lavrov]

Sorry,i can't post normal reply. It's "Re:is the writing on the wall for
ada"  is too big...


Russ wrote:
> 
> Jacob Sparre Andersen <sparre@crs4.it> wrote in message news:<3F7024F8.1000102@crs4.it>...
> > Russ wrote:
> > > Wes Groleau <groleau@freeshell.org> wrote in message news:<RbSdnT6kv7SrdPqiU-KYuQ@gbronline.com>...
> >
> > >>(Russ insists that A += 1 never needs temporaries
> > >>and that A := A + 1 always does.)
> >
> > Which as far as I know is not quite true.
> >
> > > That's not *quite* what I insist. What I insist is that, for
> > > vector/matrix operations, "+" is a *function* that must create a
> > > temporary vector/matrix and return it, and it must be *copied* to the
> > > lhs.
> >
> > I haven't got the LRM right here, but IIRC the compiler just has to
> > generate code that is _equivalent_ to that, i.e. code that gives the
> > same result.
> >
> > And at least for simple cases like matrix operations, it is possible to
> > make the compiler check if a temporary variable is needed or not.  We
> > can thus (at least in theory) leave it to the compiler to check if the
> > temporary variable is needed or not _and_ to consider which of the
> > solutions - with or without the temporary variable - is actually faster
> > on the hardware in question.
> >
> >  > On the other hand, "+=" is a *procedure* that does not
> > > necessarily need any temporaries because it can do its operations "in
> > > place". No temporaries, no extra copying.
> >
> > Yes.  But would you really like to have to mess with writing code that
> > you just as well could leave it to the compiler to generate _if_ it
> > actually would make a efficiency difference for the program?
> >
> > I prefer to leave as much work as possible to the compiler.
> >
> > > Someone else also claimed that a good Ada compiler can make "+" as
> > > efficient as "+=", but I don't see how that could be possible,
> > > considering that I could define "+" and "+=" to do anything I want.
> >
> > Remember that the compiler has access to the code for your "+" function
> > and can look at what it actually does.  This is simply a matter of
> > optimization.  And it is not really on an algorithmic level, so it
> > should be left to the compiler, unless you can prove that it is strictly
> > neccessary to improve the code beyond what you compiler manages.
> >
> > > Nothing in the language requires me to define "+" to actually do
> > > matrix addition. I could define it to write poetry if I wish.
> >
> > Yes.  But then the compiler will just notice that and optimize accordingly.
> >
> > > And let's not forget that a properly defined "+" should be able to
> > > handle sequential addition, such as A = B + C + D + E. No matter how
> > > you slice it, each of those additions needs a temporary.
> >
> > Assuming that we are discussing something nice like simple matrix
> > addition here, I don't see why.  If your hardware has an "add four
> > numbers" operation, you don't need any.  And in general should such an
> > operation be done on a per element basis, which would mean that one
> > would need one (if the operations are done sequetially) or two (if the
> > operations are done in parallel) registers in the CPU for storing
> > intermediate results.  But still: Leave this kind of optimization to the
> > compiler!
> 
> If the compiler can really do all that, then fine. But how many really
> can? Can gnat do that, for example? Or is this just one of those
> "maybe someday in the distant future," "pie in the sky" things?

If it's not done for integers as second(after constant precalc),
it's really strange.GNAT may not have it because of C.

Let's translate a:=a+b  to

mov eax,b
add a,eax
//optional checks:
jno @@noexcept
sub a,eax
 ---raise exception
@@noexcept:

> By the way, even if there is no difference in efficiency, I still
> prefer
> 
>     count += 1
> to
>     count = count + 1
> 
> The latter grates on my minimalist sensibilities like fingernails on a
> chalkboard, and I'll bet I'm not alone on this. As I said before, I'll
> bet the vast majority of C, C++, Java, Perl, and Python programmers
> use the first form. If this low-level deficiency is not corrected in
> Ada0x, that will be a big mistake.

Yes, OPERATION is needed,but it's does not mean that we really need "+="
operator.

I prefer build-in for build-in types
inc(count,1);   {like in many Pascal implementation}
to
count += 1
and to
count := count + 1

,because i really don't want to add new operators "+=","-=","*=",and
"/=" for divide(!!!;-), "\=" for a:=b/a ,and "!=" for factorial.

sin= for sine,sqrt= for squareroot,and juliafractal= for iteration of
julia fractal  . 


"procedure" notation should be used anywhere except where we need
"compatibility" with math notation.
There are no += operator in math,so we don't need operator,just
procedure(build-in for CPU-supported operations).

-- 
http://dmytrylavrov.narod.ru

Re: += in ada

[Peter Amey]

>>
>>    count = count + 1
>>
>>The latter grates on my minimalist sensibilities like fingernails on a
>>chalkboard

Surely, if you have minimalist sensibilties you would replace:

"count = count + 1"   with   "False"?


:-)

Peter

Re: += in ada

[Frank J. Lhota]

"Peter Amey" <peter.amey@praxis-cs.co.uk> wrote in message
news:ble3d6$aus9m$1@ID-69815.news.uni-berlin.de...
> Surely, if you have minimalist sensibilties you would replace:
>
> "count = count + 1"   with   "False"?

I know that using "=" for assignment goes all the way back to Fortran and
Basic, but it has always been a source of confusion. That's why I would
prefer ":=" for assignment, and "+:=" for the increment operator.

The best symbol for assignment that I have seen is a left arrow, e.g. "count
? count + 1". Visually, it is quite suggestive of assigment (the value on
the right goes into the variable on the left) and it would never be confused
with testing for equality. Both APL and early versions of Smalltalk used the
left arrow for assignment. As far as I can tell, the only reason why the
left arrow is not used more often is that it is not a standard 7-bit ASCII
character.

Re: += in ada

[Isaac Gouy]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<cVzeb.10092$kD3.2315@nwrdny03.gnilink.net>...
> "Peter Amey" <peter.amey@praxis-cs.co.uk> wrote in message
> news:ble3d6$aus9m$1@ID-69815.news.uni-berlin.de...
> > Surely, if you have minimalist sensibilties you would replace:
> >
> > "count = count + 1"   with   "False"?
> 
> I know that using "=" for assignment goes all the way back to Fortran and
> Basic, but it has always been a source of confusion. That's why I would
> prefer ":=" for assignment, and "+:=" for the increment operator.

A variation on that theme is used in CLAIRE
   := for assignment
   :+ for increment


> The best symbol for assignment that I have seen is a left arrow, e.g. "count
> ? count + 1". Visually, it is quite suggestive of assigment (the value on
> the right goes into the variable on the left) and it would never be confused
> with testing for equality. Both APL and early versions of Smalltalk used the
> left arrow for assignment. As far as I can tell, the only reason why the
> left arrow is not used more often is that it is not a standard 7-bit ASCII
> character.

Re: += in ada

[Russ]

igouy@yahoo.com (Isaac Gouy) wrote in message news:<ce7ef1c8.0310030822.26794d1c@posting.google.com>...

> A variation on that theme is used in CLAIRE
>    := for assignment
>    :+ for increment

No kidding! That's what I suggested several weeks (months?) ago. So :+
has a track record. I guess I'm not as far out as I thought I might
be.

Re: += in ada

[(see below)]

On 6/10/03 21:21, in article
bebbba07.0310061221.2af714b3@posting.google.com, "Russ"
<18k11tm001@sneakemail.com> wrote:

>>    := for assignment
>>    :+ for increment
> 
> No kidding! That's what I suggested several weeks (months?) ago. So :+
> has a track record. I guess I'm not as far out as I thought I might be.

The :? formation is inconsistent with := for Boolean operands. The only
way to avoid that is by arbitrarily restricting either the operators that
have update forms, or the mutable types that have update operators.

(I pointed this out to you last time.)
--
Bill

Re: += in ada

[Craig Carey]

On Wed, 01 Oct 2003 09:35:59 +0100, Peter Amey
<peter.amey-@-praxis-cs.co.uk> wrote to comp.lang.ada:
>Subject: Re: += in ada"
>>>
>>>    count = count + 1[;]
>>>
>>>The latter grates on my minimalist sensibilities like fingernails on a
>>>chalkboard

The arguments in favour of += that come from C programmers seem to
be arriving at comp.lang.ada.
They should be unpersuasive since ignoring the "renames" replacement for
the possible but missing "+=" operator.

Suppose this Ada code in the proposed C style, and += and -= are used:

01   A.Bcd += 1;
02   A := Z;
03   A.Bcd -= 1;

Now let A be pointer to a record containing a field named 'Bcd'.
This is the same code in Ada 95. Unlike real declarations, the renames
statement can associate a single variable name with any element of a
shiftinglist of possible memory locations. Ada has the much needed goto
which allows a solution that seems to be overly verbose:

01   No_Redo_Renaming : Boolean;
   ...
02   No_Redo_Renaming := False
03   <<REDO_RENAMING>>
04   declare
05      R : Integer renames A.all.Bcd;
06   begin
07      if No_Redo_Renaming then
08         R := R + 1;
09         A := Z;
10         No_Redo_Renaming := False;
11         goto REDO_RENAMING;
12      else
13         R := R - 1;
14      end if;
15   end;


If R is intended to denote all the different R's then the code need can
be briefer.

Arguments for new features that are inconsiderate could fail make it
all the way out to the end. Advocacy of += has so far failed to say
what is wrong with this syntax:

01   declare R : Integer renames A.all.Bcd; end;
02   R := R + 1;
03   A := Z;
04   declare R : Integer renames A.all.Bcd; end;
05   R := R - 1;

Variations on that could include:
 * "end" is replaced with "end declare;"
 * "declare is replaced with "begin declare".

What C++ programmers might now want, is to give up on saying that Ada
needs a += operator, since it seems to be a hopeless cause.

-----

This topic is also in the large thread that now has over 437 messages.
A message there that allocates failure to the "+=" proposal is this:


At 27 Sep 2003 17:43:42 -0500, "Randy Brukardt" <randy-@-rrsoftware.com>
 wrote to comp.lang.ada:
>Subject: Re: Is the Writing on the Wall for Ada? [although this thread
>      changed to something else a long time ago]
...
>In any case, I'm sympathic to the issue, but (a) I don't like this syntax,
>and there are other solutions, and (b) there are a hundred issues more
>important. I note that you didn't answer my note asking what you'd give up
>for this rather substantial change.
>
>>I've seen some weak arguments here, and this one is typical. What is
>>increasingly apparent to me is that Ada veterans are set in their
>>ways, and no amount of reason will budge them on the basic syntax of
>>Ada, even when if is deficient compared to the existing languages that
>>98% of programmers use.
...

It could be a joke: the set of unreasonable veterans is empty but the
description description parallels what suggesting big changes to C++
projects.

Mr Dewar here states that there is a need for some to get a "$" operator:

----------------------------
At 2002-11-09 22:10 -0500 Saturday, Robert Dewar wrote to
   ada-comment@ada-auth.org:
...
>Note incidentally that the grade school idea does not work for
>division, since the / operator has nothing to do with mathematics,
>where the horizontal line used for division uses a graphical technique
>to indicate precedence. In SNOBOL4 Griswold changed / to have lower
>precedence than multiplication
>
>so a*b / c*d means what it looks like, but this sure confused the
>Fortran folk.
>
><<P.S. This is fun.  I again apologize that it has little to do with the
>topic at hand.
>>>
>
>I am not sure that is the case. After all the actual topic at hand is
>useful additions to the language. Maybe allowing $ to be defined as an
>operator is just as interesting as bit string set packages :-)
>
----------------------------

Using my syntax

begin
   declare function "$" (L : lhs T; R : constant T) return T
      renames "~#="; end;

It might be nice to have constant to be like the "in" mode, except that
that objects underneath pointers are also constant, which better hide
when the objects are pointers or records.



>Ada has real technical issues that need fixing,


Some is online here:  http://www.ada-auth.org/ai-files/REST_AIS.ZIP


-----

On 24 Sep 2003 17:42:06 -0700, 18k11tm001-@-sneakemail.com (Russ) wrote
 to comp.lang.ada:

... which of the following is more readable [?]:
>
>lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno := 
>     lwienfowowoenfnowoqndfoowopqihjefhmowqoowldvno + 1
>
>or
>
>lwienfowowoenfnowoqndfoowopqihjefhnowqoowldvno += 1


Swapped an "n" with an "m".



Craig Carey

Re: += in ada

[Jean-Pierre Rosen]

I'm surprised that nobody suggested that (or I missed it), but why not define an attribute:

procedure <integer-or-modular-type>'Inc (X : in out <integer-or-modular-type>; By : <integer-or-modular-type> := 1);

No big change to the language, easy to implement....

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: += in ada

[Lutz Donnerhacke]

* Jean-Pierre Rosen wrote:
> I'm surprised that nobody suggested that (or I missed it), but why not
> define an attribute:

Because it is too special to add to the language. The idem Idiom is much
more general and addresses the problem behind the question.

Re: += in ada

[Wes Groleau]

Jean-Pierre Rosen wrote:
> I'm surprised that nobody suggested that (or I missed it), but why not define an attribute:
> 
> procedure <integer-or-modular-type>'Inc (X : in out <integer-or-modular-type>; By : <integer-or-modular-type> := 1);

Nobody suggested it this time around,
but somebody did last time (over
a year ago, I think).


-- 
Wes Groleau

    "A man wih an experience is never
     at the mercy of a man with an argument."
                       -- Ron Allen

Re: += in ada

[Gautier]

# > If the compiler can really do all that, then fine. But how many really
# > can? Can gnat do that, for example? Or is this just one of those
# > "maybe someday in the distant future," "pie in the sky" things?
# 
# If it's not done for integers as second(after constant precalc),
# it's really strange.GNAT may not have it because of C.
# 
# Let's translate a:=a+b  to
# 
# mov eax,b
# add a,eax
# //optional checks:
# jno @@noexcept
# sub a,eax
#  ---raise exception
# @@noexcept:

Dmytry, Russ: you are just speculating. GNAT (at least) *does*
simplify a:= a+b into an intrinsic "Inc(a,b)", even with a complicated
variable access instead of "a". This since (at least) the
GNAT 3.10p of 1997 !... Here is a reply (to me, who was also wrong!)
from Samuel Tardieu on the same topic a few years ago:

"
Where did you get the impression that the optimizer would miss this? 
 For example, using GNAT, the following expression generates: (ix86 code) 
                           
 t__pXb: movl t__jXb,%edx                             |
         decl %edx                                    |
         movl t__iXb,%eax                             |
         decl %eax                                    |
         leal (%eax,%eax,4),%eax                      |
         sall $3,%eax                                 |
         leal (%eax,%edx,4),%edx                      |
         movl t__gXb,%ecx                             |
         decl %ecx                                    | Address computation
         movl t__fXb,%eax                             |
         decl %eax                                    |
         leal (%eax,%eax,4),%eax                      |
         sall $3,%eax                                 |
         movl t__eXb(%eax,%ecx,4),%eax                |
         addl t__dXb,%eax                             |
         imull $400,%eax,%eax                         |
         leal -400(%edx,%eax),%eax                    |
         imull $4000,t__cXb,%edx                      |
         movl t__bXb-4000(%eax,%edx),%eax             |
         decl %eax                                    |
         incl t__aXb(,%eax,4)            <--- Increment done here!
         ret
                           
 The code used to generate this was: (-O3 -fomit-frame-pointer -gnatp) 
                           
 package T is
   pragma Elaborate_Body;
 end T;
                           
 package body T is
   pragma Warnings (Off); -- Uninitialized variables
                           
   type Two_Ints is array (Integer range <>, Integer range <>) of Integer; 
                           
   type Rec is record
     H : Two_Ints (1 .. 10, 1 .. 10);
   end record;
                           
   type Two_Recs is array (Integer range <>, Integer range <>) of Rec; 
                           
   A : array (1 .. 10) of Integer;
   B : Two_Recs (1 .. 10, 1 .. 10);
   C : Integer;
   D : Integer;
   E : Two_Ints (1 .. 10, 1 .. 10);
   F : Integer;
   G : Integer;
   I : Integer;
   J : Integer;
                           
   procedure P is
     begin
       a(b(c,d+e(f,g)).h(i,j)) :=  a(b(c,d+e(f,g)).h(i,j)) + 1;
     end P;
                           
 end T;
"

The issue is then not an optimization problem, but an
readbility & verifiability one. An Inc(a,b) guaranteed
with pragma Intrinsic by the next Standard would be just fine.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: += in ada

[Lutz Donnerhacke]

* Gautier wrote:
> The issue is then not an optimization problem, but an
> readbility & verifiability one. An Inc(a,b) guaranteed
> with pragma Intrinsic by the next Standard would be just fine.

The "idem"-Idiom would be much better.
  X(b(i).all+7) := idem + 2/idem;

And please do not forget the exception handling: "a += b" should keep the
value of a and b when detecting an overflow!

Re: += in ada

[Preben Randhol]

On 2003-10-02, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> The "idem"-Idiom would be much better.
>   X(b(i).all+7) := idem + 2/idem;

The problem I have with idem is that it looks like just another
variable.

> And please do not forget the exception handling: "a += b" should keep the
> value of a and b when detecting an overflow!

Exactly.

Re: += in ada

[Lutz Donnerhacke]

* Preben Randhol wrote:
> On 2003-10-02, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
>> The "idem"-Idiom would be much better.
>>   X(b(i).all+7) := idem + 2/idem;
>
> The problem I have with idem is that it looks like just another
> variable.

I insist on the semantical meaning, but not on the syntactical term.

Re: += in ada

[Keith Thompson]

Lutz Donnerhacke <lutz@iks-jena.de> writes:
> * Preben Randhol wrote:
> > On 2003-10-02, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> >> The "idem"-Idiom would be much better.
> >>   X(b(i).all+7) := idem + 2/idem;
> >
> > The problem I have with idem is that it looks like just another
> > variable.
> 
> I insist on the semantical meaning, but not on the syntactical term.

Didn't somebody once suggest "@" for this?

    X(b(i).all+7) := @ + 2/@;

There might be some concern about systems that don't have "@" in their
character sets, but they can't send e-mail so we don't have to worry
about their complaints.  8-)}

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: += in ada

[Russ]

Keith Thompson <kst@cts.com> wrote in message news:<lzwubns4v8.fsf@cts.com>...
> Lutz Donnerhacke <lutz@iks-jena.de> writes:
> > * Preben Randhol wrote:
> > > On 2003-10-02, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> > >> The "idem"-Idiom would be much better.
> > >>   X(b(i).all+7) := idem + 2/idem;
> > >
> > > The problem I have with idem is that it looks like just another
> > > variable.
> > 
> > I insist on the semantical meaning, but not on the syntactical term.
> 
> Didn't somebody once suggest "@" for this?
> 
>     X(b(i).all+7) := @ + 2/@;

Yes, I did. I think "@" is appropriate because it represents what is
"at" the location that is about to be overwritten. But I don't think
this notation is as good as ":+", etc. Yes, it *is* more general, but
that generality is rarely needed.

Re: += in ada

[Dmytry Lavrov]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0310061641.2ec215c6@posting.google.com>...
> Keith Thompson <kst@cts.com> wrote in message news:<lzwubns4v8.fsf@cts.com>...
> > Lutz Donnerhacke <lutz@iks-jena.de> writes:
> > > * Preben Randhol wrote:
> > > > On 2003-10-02, Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> > > >> The "idem"-Idiom would be much better.
> > > >>   X(b(i).all+7) := idem + 2/idem;
> > > >
> > > > The problem I have with idem is that it looks like just another
> > > > variable.
> > > 
> > > I insist on the semantical meaning, but not on the syntactical term.
> > 
> > Didn't somebody once suggest "@" for this?
> > 
> >     X(b(i).all+7) := @ + 2/@;
> 
> Yes, I did. I think "@" is appropriate because it represents what is
> "at" the location that is about to be overwritten. But I don't think
> this notation is as good as ":+", etc. Yes, it *is* more general, but
> that generality is rarely needed.
:+ ???
what with := and boolean operators?

about "@"
it's look like attempt to make things more readable by replacing firse
operand in expression by @ (@1),second by @2,third by @3....
c:=(a+b)*@2*@4+@1 ; ;-)
where @1=c; @2=a; @3=b; @4=(a+b); @5=@2; @6=@4; @7=(a+b)*@2*@4;

Maybe for first it's good,but...

i think it's better to use something like
begin
@ is X(b(i).all+7);@:=@+2/@;
end;
or,more generally,to use something like
begin
declare_new_name a _for_ X(b(i).all+7);
-- for example, "a is X(b(i).all+7)"
a:=a+2/a;
end;
(and something like that already are in ada,but while i'm beginner in
ada,i can't remember)


"+=" is a idea about in-place operations,and @ is about readability.

IMO,in place operations should be used as normal procedures like
inc(a,b) or juliafractalstep(z,c);, not like "+=","-=","*=",and "/=",
"a\=b" for a:=b/a;, and i don't know what for matrixes a:=b*a;,maybe
"\*=" or simply "\*"

even with ":=","=:",or ":" instead of "=",or with any char,it's still
be bad.


Dmytry Lavrov,

http://dmytrylavrov.narod.ru

Re: += in ada

[Lutz Donnerhacke]

* Dmytry Lavrov wrote:
> begin
> declare_new_name a _for_ X(b(i).all+7);
> -- for example, "a is X(b(i).all+7)"
> a:=a+2/a;
> end;

declare
   a : Typ renames X(b(i).all + 7);
begin
   a := a + 2/a;
end;   

is legal Ada and a common idiom.

> "+=" is a idea about in-place operations,and @ is about readability.

Both ideas fail on considering a consitent semantic for volatile types and
exception handling. In both cases it's necessary to require a temporary copy
of the LHS. So nothing is gained from this proposal, beside a clear semantic
about access frequency for volatile data (one read and one write access).

So I have to conlude, that the whole "idem" Idiom is useless at all.

In order to generate a more general solution, the S'Type attibute would
helpful, because it's possible to write:

declare
   a : a'Type renames X(b(i).all + 7);
begin
   a := a + 2/a;
end;   

> IMO,in place operations should be used as normal procedures like
> inc(a,b) or juliafractalstep(z,c);

Yep.

Re: += in ada

[(see below)]

On 7/10/03 12:56, in article slrnbo5afo.o7.lutz@taranis.iks-jena.de, "Lutz
Donnerhacke" <lutz@iks-jena.de> wrote:

> declare
>  a : Typ renames X(b(i).all + 7);
> begin
>  a := a + 2/a;
> end;   
> 
> is legal Ada and a common idiom.

Not always legal, see below.
 
> Both ideas fail on considering a consitent semantic for volatile types and
> exception handling. In both cases it's necessary to require a temporary copy
> of the LHS. So nothing is gained from this proposal, beside a clear semantic
> about access frequency for volatile data (one read and one write access).
> 
> So I have to conlude, that the whole "idem" Idiom is useless at all.

Some time ago, I posted this:

> 1. It lets the programmer indicate that the occurrences of the LHS in the
> RHS are *necessarily* the same, and not contingently so, which makes the
> code more self-documenting.
> 2. It removes a source of error in transcribing the LHS multiple times.
> 3. It allows more concisely readable code when the LHS is lengthy.
> 4. It provides functionality that it only partially available by means of
> much clumsier renaming declarations, because not all objects can be renamed.
> 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
> that lvalue as often as needed to evaluate the RHS. This has three potential
> benefits: shorter code, faster execution, and once-only invocation of any
> side effects.
> 6. It might make it somewhat easier for the compiler to generate
> update-in-place object code, where the target architecture allows that and
> where it offers a performance advantage.
> 7. It provides all the utility of C's multitude of combined assignment
> operators with one small, compatible change to the syntax of operands.
> (I specify C, rather than C++, to avoid getting into a argument about
> overloading assignment).
> 8. It allows the expression of useful forms that C's combined assignment
> operators cannot achieve (e.g. X := 1 - idem;).

You regard all of these benefits as "useless"?
-- 
Bill

Re: += in ada

[Russ]

"(see below)" <yaldnifb@blueyonder.co.uk> wrote in message news:<BBA885C7.5DECA%yaldnifb@blueyonder.co.uk>...
> On 7/10/03 12:56, in article slrnbo5afo.o7.lutz@taranis.iks-jena.de, "Lutz
> Donnerhacke" <lutz@iks-jena.de> wrote:

> > So I have to conlude, that the whole "idem" Idiom is useless at all.
> 
> Some time ago, I posted this:
> 
> > 1. It lets the programmer indicate that the occurrences of the LHS in the
> > RHS are *necessarily* the same, and not contingently so, which makes the
> > code more self-documenting.

The proposed augmented assignment operators ":+", ":-", ":*", and ":/"
do even better than that. They make the LHS and RHS one and the same.

> > 2. It removes a source of error in transcribing the LHS multiple times.

Ditto for ":+", etc.

> > 3. It allows more concisely readable code when the LHS is lengthy.

Ditto for ":+", etc.

> > 4. It provides functionality that it only partially available by means of
> > much clumsier renaming declarations, because not all objects can be renamed.

Ditto for ":+", etc.

> > 5. It requires the compiler to evaluate the lvalue of the LHS once and reuse
> > that lvalue as often as needed to evaluate the RHS. This has three potential
> > benefits: shorter code, faster execution, and once-only invocation of any
> > side effects.
> > 6. It might make it somewhat easier for the compiler to generate
> > update-in-place object code, where the target architecture allows that and
> > where it offers a performance advantage.

Replace "might" with "will" for ":+", etc. Augmented assignment gives
control over to the programmer, where it belongs, who can guarantee
update-in-place efficiency with proper basic design, as opposed hoping
or praying that every compiler does the job right.

> > 7. It provides all the utility of C's multitude of combined assignment
> > operators with one small, compatible change to the syntax of operands.
> > (I specify C, rather than C++, to avoid getting into a argument about
> > overloading assignment).
> > 8. It allows the expression of useful forms that C's combined assignment
> > operators cannot achieve (e.g. X := 1 - idem;).

Yes, but the vast majority of uses in practice will be for simple
incrementing, multiplying in place, etc. The "idem" construct is
overkill. I have no objection to the proposal, but I think it would be
a mistake to let it crowd out the simpler augmented assignment
operators.

Repeat after me: Augmented assignment is available and WIDELY USED in
C, C++, Java, Perl, and Python, perhaps the 5 most popular
general-purpose programming languages ever designed. Is it *possible*
that 98% of the programmers out there might know *something* that Ada
programmers don't?

Re: += in ada

[(see below)]

On 7/10/03 23:22, in article
bebbba07.0310071422.5af7850f@posting.google.com, "Russ"
<18k11tm001@sneakemail.com> wrote:

> Repeat after me: Augmented assignment is available and WIDELY USED in
> C, C++, Java, Perl, and Python, perhaps the 5 most popular
> general-purpose programming languages ever designed.

Russ, if you tried to be less patronising, your arguments *might* find a
less dismissive audience.

> Is it *possible* that 98% of the programmers out there might know
> *something* that Ada programmers don't?

Is it *possible* that Ada programmers who do not agree with you might also
be experienced C programmers and know its features only too well? Further,
is it possible that they might be right, and that *you* might be wrong?

-- 
Bill

Re: += in ada

[Preben Randhol]

On 2003-10-07, Russ <18k11tm001@sneakemail.com> wrote:
> Repeat after me: Augmented assignment is available and WIDELY USED in
> C, C++, Java, Perl, and Python, perhaps the 5 most popular
> general-purpose programming languages ever designed. Is it *possible*
> that 98% of the programmers out there might know *something* that Ada
> programmers don't?

So what? A billion Chinese speak Chinese...

Do you want the pointer arithmic of C too?

Preben who gets a bit tired of this attitude.

Re: += in ada

[Russ]

Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote in message news:<slrnbo7afh.1rc.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no>...
> On 2003-10-07, Russ <18k11tm001@sneakemail.com> wrote:
> > Repeat after me: Augmented assignment is available and WIDELY USED in
> > C, C++, Java, Perl, and Python, perhaps the 5 most popular
> > general-purpose programming languages ever designed. Is it *possible*
> > that 98% of the programmers out there might know *something* that Ada
> > programmers don't?
> 
> So what? A billion Chinese speak Chinese...

Does 98% of the world population speak Chinese?

> Do you want the pointer arithmic of C too?

Do C, C++, Java, Perl, and Python *all* have pointer arithmetic? Of
course not. Only C and C++ have it. My point was that all five of
those languages -- the most popular general-purpose languages in
current use -- *all* have augmented assignment.

What am I to make about your missing such a clearly stated point? Do
you deliberately *try* to miss the point when you don't want to hear
it?

> Preben who gets a bit tired of this attitude.

And I get tired of people who assume that I want augmented assignment
operators in Ada only because they are in C/C++. I'll tell you
straight out that I have no fondness for C and C++, so please dump
that strawman.

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Russ wrote:

>Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote in message news:<slrnbo7afh.1rc.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no>...
>> On 2003-10-07, Russ <18k11tm001@sneakemail.com> wrote:
>> > Repeat after me: Augmented assignment is available and WIDELY USED in
>> > C, C++, Java, Perl, and Python, perhaps the 5 most popular
>> > general-purpose programming languages ever designed. Is it *possible*
>> > that 98% of the programmers out there might know *something* that Ada
>> > programmers don't?
>> 
>> So what? A billion Chinese speak Chinese...
>
>Does 98% of the world population speak Chinese?

Well, *much* less than 98% of the world population are programmers,
I'd say. :)

>course not. Only C and C++ have it. My point was that all five of
>those languages -- the most popular general-purpose languages in
>current use -- *all* have augmented assignment.

Inhouse we have a term for that: "Historical reason". ;)

That means "dirty, little thing that's just there and nobody wants to
touch it, because if you'd do, it'll surely break some time".

>And I get tired of people who assume that I want augmented assignment
>operators in Ada only because they are in C/C++.

Well, if at all, I would like to have the idem approach like it was
discussed long before here in c.l.a.:

|A_Complex_Left_Hand_Side := <idem> + 1;

instead of (your) proposed

|A_Complex_Left_Hand_Side :+= 1;

IMO, the latter *is* too confusing, no matter how the operator would
exactly look like.

It would give you all you want and would even include the plus of
being more versatile, because one could use it more than once in a
line.

A perhaps second argument is: it wouldn't clutter up the code too
much, because probably no one would try to write

|i := <idem> + Another_Variable;

instead of

|i := i + Another_Variable;

in this simple case, but surely a lot of people would use

|i :+= Another_Variable;

because it might be easier/faster to write. So this could be sort of
self-regulating. :)


Vinzent.

Re: += in ada

[Preben Randhol]

On 2003-10-10, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> Vinzent 'Gadget' Hoefler fed this fish to the penguins on Thursday 09 
> October 2003 12:42 pm:
>
>
>> 
>> Inhouse we have a term for that: "Historical reason". ;)
>> 
>> That means "dirty, little thing that's just there and nobody wants to
>> touch it, because if you'd do, it'll surely break some time".
>>
>         Regretably, in the case of Python, it was not "historical reason"... 
> The BDFL succumbed to the demands of the C-slaves and added the feature 
> (think they arrived with v2.1 of Python, maybe v2.2... v2.3 has only 
> recently been released).
>

Yes exactly. The problem is when people think something is a great idea
merly because everybody else does/uses it. Most cases it is not so.

Preben

Re: += in ada

[Russ]

Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote in message news:<slrnbocods.gq.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no>...
> On 2003-10-10, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> > Vinzent 'Gadget' Hoefler fed this fish to the penguins on Thursday 09 
> > October 2003 12:42 pm:
> >
> >
> >> 
> >> Inhouse we have a term for that: "Historical reason". ;)
> >> 
> >> That means "dirty, little thing that's just there and nobody wants to
> >> touch it, because if you'd do, it'll surely break some time".

That may apply to C++, but it does not apply to Java, Perl, and
Python.

> >         Regretably, in the case of Python, it was not "historical reason"... 
> > The BDFL succumbed to the demands of the C-slaves and added the feature 
> > (think they arrived with v2.1 of Python, maybe v2.2... v2.3 has only 
> > recently been released).

Sorry, but that's a gross distortion. Guido Von Rossom himself wanted
augmented assignment operators.

> Yes exactly. The problem is when people think something is a great idea
> merly because everybody else does/uses it. Most cases it is not so.

You have a very strong proclivity for twisting what I say. I did *not*
say that anything is a great "because everybody else does/uses it".
What I said is that "everybody else does/uses it" *because* it is a
great idea. Those are two very different claims.

It is becoming clear to me that debating with you is like sparring
with one of those bottom-heavy clown dummies that always right
themselves regardless of how hard you hit them. No matter what I say,
you aggressively miss the point and come back with the same tired old
crap.

I sincerely hope that your attitude is not representative of the
entire Ada community, because if it is, Ada is doomed. Then again, it
may be doomed anyway -- unfortunately.

Re: += in ada

[Preben Randhol]

On 2003-10-10, Russ <18k11tm001@sneakemail.com> wrote:
> You have a very strong proclivity for twisting what I say. I did *not*
> say that anything is a great "because everybody else does/uses it".
> What I said is that "everybody else does/uses it" *because* it is a
> great idea. Those are two very different claims.

No. You used the "everybody else" as an argument/weight to your claim
that it is a great idea. Besides I was not refering to you in
particular, but the notion that "everybody else does it" is a valid
argument for something being a Good Idea(tm)-

> It is becoming clear to me that debating with you is like sparring
> with one of those bottom-heavy clown dummies that always right
> themselves regardless of how hard you hit them. No matter what I say,
> you aggressively miss the point and come back with the same tired old
> crap.

Well, maybe but you have throughout the += :+= :+ argumentation
protraied yourself as an arrogant person who thinks everybody else is
stupid (you even more or less have said so to several people here) so I
do not take you too seriously unfortunately.

> I sincerely hope that your attitude is not representative of the
> entire Ada community, because if it is, Ada is doomed. Then again, it
> may be doomed anyway -- unfortunately.

Hehehehehe Why is the Ada community doomed because one do not want
augmented assignment? Now, I would rather you'd answer my direct
question to you.

Preben

Re: += in ada

[Samuel Tardieu]

>>>>> "Russ" == Russ  <18k11tm001@sneakemail.com> writes:

Russ> Guido Von Rossom himself wanted augmented assignment operators.

His name is "Guido van Rossum".

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Dennis Lee Bieber wrote:

>Vinzent 'Gadget' Hoefler fed this fish to the penguins on Thursday 09 
>October 2003 12:42 pm:
>
>> Inhouse we have a term for that: "Historical reason". ;)
>> 
>> That means "dirty, little thing that's just there and nobody wants to
>> touch it, because if you'd do, it'll surely break some time".
>>
>        Regretably, in the case of Python, it was not "historical reason"... 
>The BDFL succumbed to the demands of the C-slaves

Exactly. This *is* a Historical Reason: The dirty little thing was
added because it was already there somewhere else. :)


Vinzent.

Re: += in ada

[Preben Randhol]

On 2003-10-09, Russ <18k11tm001@sneakemail.com> wrote:
>> So what? A billion Chinese speak Chinese...
>
> Does 98% of the world population speak Chinese?

No, but according to your logic one should.

>> Do you want the pointer arithmic of C too?
>
> course not. Only C and C++ have it. My point was that all five of
> those languages -- the most popular general-purpose languages in
> current use -- *all* have augmented assignment.

So? All are derivatives of C. Ada is not.

> What am I to make about your missing such a clearly stated point? Do
> you deliberately *try* to miss the point when you don't want to hear
> it?

Try ask yourself the same question! How do you circumvent the
requirement in RM about not altering the value of the variable if a
exception occurs?

> And I get tired of people who assume that I want augmented assignment
> operators in Ada only because they are in C/C++. I'll tell you
> straight out that I have no fondness for C and C++, so please dump
> that strawman.

Is it strange? With the arguments you present?

Preben

Re: += in ada

[Wes Groleau]

Preben Randhol wrote:
> Try ask yourself the same question! How do you circumvent the
> requirement in RM about not altering the value of the variable if a
> exception occurs?

There is NOT a requirement in the RM that += not
alter the value of any variable when an exception
occurs.  There is no requirement in the RM that "+="
do anything or not do anything.  IF we decide to put
such a thing in the RM, THEN we will decide what its
requirements will be.  Until then, there are no requirements
to circumvent.

-- 
Wes Groleau
-----------
Daily Hoax: http://www.snopes2.com/cgi-bin/random/random.asp

Re: += in ada

[Preben Randhol]

On 2003-10-12, Wes Groleau <groleau@freeshell.org> wrote:
> There is NOT a requirement in the RM that += not
> alter the value of any variable when an exception
> occurs.  There is no requirement in the RM that "+="

No, but for := it is.

Preben

Re: += in ada

[Robert I. Eachus]

Preben Randhol wrote:

> No, but for := it is.

Let me jump in here.  I'll also include comments by my alter ego Bob 
which should sound supiously like what Bob Duff would say.

Bob: Not anymore.  In Ada 95 if you have an assignment to Foo in a scope 
where Constraint_Error occurs, the value of Foo may become abnormal. See 
11.6(6).

Robert: That is misleading in this case.  If the type of Foo is a scalar 
for which assignment is indivisible (see C.6), the only possible values 
of Foo visible in an exception handler are the value before the 
assignment, and the value after.  If this is the only potential 
assignment to Foo in this scope, then the value is well defined.

Bob:  The only way to ENSURE that the assignment is indivisible is to 
apply pragma Atomic to the type or to Foo.

Robert:  Not quite.  Foo could also be Volitile, or a component of a 
Volitile type.  But that is irrelevant in this context.  An assignment 
may be indivisible whether or not pragma Volitile or Atomic applies.

Bob:  But the user can't know that for sure.  Imagine a (packed) record 
type with an Integer component that begins at an odd bit offset.  The 
compiler may have to do a non-indivisible assignment in that case even 
if assignments to Integers are normally indivisible.

Robert: Correct, and in that case, the user would deserve what he got. 
But note that the user could do the assignment (and Constrain_Error 
check) in a subprogram in this case.  The value of Foo would be pased by 
value return if the parameter was in out.  The constraint check inside 
the subprogram, and the handler for the exception, would see the value 
as indivisible.

Bob: But only if the subprogram was not inlined!

Robert: Right.  Well not quite right.  If there was a pramga Inline for 
the subprogram, what Bob says is true.  But in this case automatic 
inlining by the compiler must preserve the required semantics.

Bob: But the compiler is not REQUIRED to use an indivisible assignment 
unless pragma Volitile or Atomic, etc., applies...

At this point we will leave the discussion which could continue long 
into the night.  (And I am writing this at 11 o'clock in the morning!) 
Forcing any compiler to "do the right thing" is possible, but in 99% of 
the cases it will happen by default.  The compiler is allowed to break 
the assignment of an unaligned component into several operations, and 
that CAN be visible in an exception handler.  But in almost all cases 
this won't happen.  If you are a belt and suspenders type, and you are 
writing code you want to be portable, you may want to use Atomic or 
Volitile.  Notice that there can be a performance penalty for doing so.
-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[(see below)]

On 12/10/03 15:57, in article 3F896BAB.6040804@comcast.net, "Robert I.
Eachus" <rieachus@comcast.net> wrote:

> Let me jump in here.  I'll also include comments by my alter ego Bob
> which should sound supiously like what Bob Duff would say.
...

So, Robert and/or "Bob", would it be acceptable to the Guardians Of Ada's
Purity if the semantics of a new "idem" feature were to specify that:
   x := f(idem);
could leave an arbitrary value in x in the event of a Constraint_Error being
raised; thus always permitting an update-in-place implementation?
-- 
Bill:Findlay chez Blue:Yonder dot:co:dot:uk (":" => "")

Re: += in ada

[Robert I. Eachus]

> So, Robert and/or "Bob", would it be acceptable to the Guardians Of Ada's
> Purity if the semantics of a new "idem" feature were to specify that:
>    x := f(idem);
> could leave an arbitrary value in x in the event of a Constraint_Error being
> raised; thus always permitting an update-in-place implementation?

Robert would say no, Bob would say yes.  The ARG would spend a couple of 
hours discussing it and not change the current situation. ;-)  In other 
words, right now IF you need to you can write things so that x won't get 
corrupted.  Also you will normally get the fastest possible code 
generated.  It is only when those two principles collide that there is 
an issue.  Robert was happier with the Ada 83 rules.  Bob prefers the 
Ada 95 rules.  But in 90+ percent of the cases where Constraint_Error 
can occur, there are no practical differences between the rules.

If you are really concerned with insuring that the value of x doesn't 
get assigned a value even temporarily out of range, the new rules are 
more difficult to understand and follow.  Of course Bob would say that 
if you want good code, the Ada 95 rules are easier to work with.  The 
funny thing about all this is that in the debates about 11.6 over the 
years, people named Robert or Bob have been very active and vocal in 
expressing all possible points of view, mostly Bob Duff, Robert Dewar, 
and myself.  Bob Duff and I come the closest to being the Robert and Bob 
of the dialog, and Robert Dewar can certainly pinch hit for either one 
of us.

But that gets back to something that is hard to explain to people who 
haven't sat in on an ARG meeting.  It is a very strenous intellectual 
exercise, but we are all concerned with insuring that all possible 
issues are examined before the ARG makes a decision.  If you look at the 
history of some issues, we would meet vote 10-0 for some position and 
delegate someone to write the decision up.  The draft AI would then get 
voted down say 8-3, a new position agreed to, and the process repeated. 
  I'd have to check what the record on a single AI was, but Ada 83 
AI-315 was about this issue and was never completely resolved.  A lot of 
the new language in Ada 95 is supposed to resolve it, and I have yet to 
see a serious complaint from outside the ARG.  But it is an extremely 
difficult issue.  Let me give you the canonical problem, and see if you 
want to take a shot at it:

with Text_IO; use Text_IO;
with Integer_Text_IO; use Integer_Text_IO;
procedure Issue is
   X,Y,Z: Integer := 0;
begin
   Get(X); Get(Y);
   if X * Y > Integer'Last
   then
     Put_Line("Overflow!");
   else
     Z := X * Y;
     Put_Line("Okay");
   end if;
exception when Constraint_Error =>
   Put("Exception Raised. Z = ");
   Put(Z);
   New_Line;
end Issue;

What is the correct behavior for this program, if (mathematically) X 
times Y is greater than Integer'Last?  In Ada 83, in theory you could 
have a compiler that legally printed Okay, Overflow, or Exception 
Raised.  In Ada 95 we think we have ruled out Okay, but doing so is 
tough.  Of course the argument we are having here is about the value of 
Z in the exception handler.  That is a much easier issue than whether 
you get Overflow or Exception Raised.  (If it matters to you, consider 
it implementation dependent, and test the exact code you care about.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Dmytry Lavrov]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message 
....
to save or not to save.
....

Here
a:=a+b;
('a+=b')

,value of a should not be corrupted,because it may be needed to find
what to do  in case of exception!
in a:=a+b it's simple to recover old value of a,but
a:=a*b;  here it's not so simple.

Of course in your example are no difference:
a:=b*c;
here we ready to lost value of a and don't use a in expression,and
normally(not in speculative examples) don't need to use a in case of
exception.If we have exception handling for expression,normally this
exception handler is a logically "part of expression",and normally may
use all values from right side of :=,to find value for left side.
 
> with Text_IO; use Text_IO;
> with Integer_Text_IO; use Integer_Text_IO;
> procedure Issue is
>    X,Y,Z: Integer := 0;
> begin
>    Get(X); Get(Y);
>    if X * Y > Integer'Last
>    then
>      Put_Line("Overflow!");
>    else
>      Z := X * Y;
>      Put_Line("Okay");
>    end if;
> exception when Constraint_Error =>
>    Put("Exception Raised. Z = ");
>    Put(Z);
>    New_Line;
> end Issue;
What,there are exception in X * Y > Integer'Last 
if there are overflow on X*Y?
And if so,how Put_Line("Overflow!"); could work?

(yes ,i'm is a newbie to ada)

Re: += in ada

[Robert I. Eachus]

Dmytry Lavrov wrote:

> What,there are exception in X * Y > Integer'Last 
> if there are overflow on X*Y?

There is a rule that used to be in 11.6 in Ada 83, but was moved to 
4.5(10).  It says that predefined arithmetic can either return the 
mathematically correct result or raise Constraint_Error.  So it is legal 
to get the "right" answer here (True) without raising Constraint_Error.

The reason that the rule is needed is that code like:  X := A + B + C; 
could have A (statically) equal to Integer'LAST, B = 10 and C the 
constant -100.  We want to allow the compiler to compute the result as 
A+C (evaluated at compile time) + B.

Oh, and in my comment on the primality of 2**31-1, I should have pointed 
out that there are a few sets of values where X*Y = Integer'LAST.  (When 
X or Y is 1 or -1.)
-- 
                                          Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> > So, Robert and/or "Bob", would it be acceptable to the Guardians Of Ada's
> > Purity if the semantics of a new "idem" feature were to specify that:
> >    x := f(idem);
> > could leave an arbitrary value in x in the event of a Constraint_Error being
> > raised; thus always permitting an update-in-place implementation?
>
> Robert would say no, Bob would say yes.  The ARG would spend a couple of 
> hours discussing it and not change the current situation. ;-)  In other 
> words, right now IF you need to you can write things so that x won't get 
> corrupted.  Also you will normally get the fastest possible code 
> generated.  It is only when those two principles collide that there is 
> an issue.  Robert was happier with the Ada 83 rules.  Bob prefers the 
> Ada 95 rules.  But in 90+ percent of the cases where Constraint_Error 
> can occur, there are no practical differences between the rules.

Isn't it exactly one of the situations for which pragmas exist? Both sides
have their good arguments (which are adequate for different circumstances),
battlefield is isolated, and collisions are relatively rare. Why not (as all
these conditions are established) introduce a pragma and thus close the issue?



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Alexandre E. Kopilovitch wrote:

>Robert I. Eachus wrote:
>
>> an issue.  Robert was happier with the Ada 83 rules.  Bob prefers the 
>> Ada 95 rules.  But in 90+ percent of the cases where Constraint_Error 
>> can occur, there are no practical differences between the rules.
>
>Isn't it exactly one of the situations for which pragmas exist? Both sides
>have their good arguments (which are adequate for different circumstances),
>battlefield is isolated, and collisions are relatively rare. Why not (as all
>these conditions are established) introduce a pragma and thus close the issue?

Well, I am not sure if this argument really would apply here, but
pragmas should not change the semantics of correct code...


Vinzent.

Re: += in ada

[Robert I. Eachus]

Vinzent 'Gadget' Hoefler wrote:

> Well, I am not sure if this argument really would apply here, but
> pragmas should not change the semantics of correct code...

There used to be a rule in Ada that pragmas, other than language defined 
pragmas should not change the meaning of a program.  That rule has been 
considerably changed in Ada 95, and distributed throughout ARM 1.1.3.

But that certainly doesn't apply to this case.  A pragma that chose one 
of several legal interpretations of a section of code would be perfectly 
fine.  But again, that is really irrelevant.  If you have a compiler 
that implements Annex H, the Safety and Security Annex, you will find 
that the pragmas Reviewable and Inspection_Point are sufficient for what 
Robert wants--canonical exception behaviour.  (pragma Reviewable applies 
to an entire partition, Inspection_Point forces canonical behavior for 
one or more variables at a particular point.  Much nicer for this 
application.) No pragma should be needed for what Bob wants, but usually 
you will find you need to set compiler options for optimization levels.
-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: ARG process (was += in ada)

[Randy Brukardt]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F89F4E9.7050601@comcast.net...
...
> But that gets back to something that is hard to explain to people who
> haven't sat in on an ARG meeting.  It is a very strenous intellectual
> exercise, but we are all concerned with insuring that all possible
> issues are examined before the ARG makes a decision.  If you look at the
> history of some issues, we would meet vote 10-0 for some position and
> delegate someone to write the decision up.  The draft AI would then get
> voted down say 8-3, a new position agreed to, and the process repeated.
>   I'd have to check what the record on a single AI was...

I can't say in general, but since my watch began (1998), the record is
AI95-00147. It was approved at meetings 4 times; the first three, new issues
surfaced afterwards, causing it to go back. It took six years to finish.

                    Randy.

Re: ARG process (was += in ada)

[Robert I. Eachus]

Randy Brukardt wrote:

> I can't say in general, but since my watch began (1998), the record is
> AI95-00147. It was approved at meetings 4 times; the first three, new issues
> surfaced afterwards, causing it to go back. It took six years to finish.

I can't say for sure, but in Ada 83 it was probably AI-2,7,50 or AI-315. 
  Of course, AI-315 probably holds a different record.  I don't think we 
EVER got as far as an approved AI.  AI-315 was about exceptions and 
optimization.  The horrible example case was:

X,Y: Integer;

declare
   Junk: Integer;
begin
   Get(X);
   Get(Y);
   Junk := X * Y;
exception
   when Constraint_Error => Do_Something;
end;

The goal of course, is to determine if X*Y > Integer'Last.  But 11.6 
allowed the multiplication and the (potential) exception to be removed.

The problem is fixed in Ada 95.  The "effect" of a program is defined, 
rather than allowing a compiler to decide to eliminate code because a 
particular value is not used.  Of course, in Ada 83 there was no real 
need to "fix" the language as long as no compiler tried to get too 
agressive in eliminating dead code.  Since all compiler vendors were 
aware of the problem, they tended to avoid that particular optimization.

Yes, dead code elimination is important in a good optimizer.  But the 
optimizer and code generator can check if a variable is a compiler 
generated temporary or a user declared variable.  Eliminating user 
declared variables entirely (and the constraint checks on its value) 
was the potentially upsetting case, eliminating compiler generated 
temporaries was not a problem.

-- 
                                            Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Dmytry Lavrov]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0310091107.6c0c3716@posting.google.com>...
> Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote in message news:<slrnbo7afh.1rc.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no>...
> > On 2003-10-07, Russ <18k11tm001@sneakemail.com> wrote:
> > > Repeat after me: Augmented assignment is available and WIDELY USED in
> > > C, C++, Java, Perl, and Python, perhaps the 5 most popular
> > > general-purpose programming languages ever designed. Is it *possible*
> > > that 98% of the programmers out there might know *something* that Ada
> > > programmers don't?
98% of ada programmers can code in at least one of listed languages.
And more than 99% of programmers can't code in ada.
Knowledge of averadge ada programmer is highter than average 
C, C++, Java, Perl, Python,and PHP ,at least because there are no
scripting kids in ada,and because ada is not popular.
Look at comp.lang.java,filled with stupid college homework-related
questions.

Here you're saying: let's be with masses,masses can't make mistakes.
i guess,more than 90% of non-school-age population can only
summ,substract,multiply and divide,but big precent was able to do many
cool things like algebraic and even trigs in school.(but some precent
can remember all this things with books)

Let's use c++ and don't touch ada.99% of programmers don't know ada.

I'm is a beginner in ada,moving from Free Pascal(and also i can code
in java and c) where(if FP too) += are supported, and I DON'T WANT +=
.
Even beginners don't want it!

> > 
> > So what? A billion Chinese speak Chinese...
> 
> Does 98% of the world population speak Chinese?
> 
> > Do you want the pointer arithmic of C too?
> 
> Do C, C++, Java, Perl, and Python *all* have pointer arithmetic? Of
> course not. Only C and C++ have it. My point was that all five of
> those languages -- the most popular general-purpose languages in
> current use -- *all* have augmented assignment.
> 
> What am I to make about your missing such a clearly stated point? Do
> you deliberately *try* to miss the point when you don't want to hear
> it?
> 
> > Preben who gets a bit tired of this attitude.
> 
> And I get tired of people who assume that I want augmented assignment
> operators in Ada only because they are in C/C++. I'll tell you
> straight out that I have no fondness for C and C++, so please dump
> that strawman.

Re: += in ada

[Dmytry Lavrov]

There are only one way to add "+=" (into ada and other languages) i
would like:
we should have something like this or language will be incomplete


procedure inc(in out a:integer;in b:integer);infix;
-- procedure-operator should always have zero priority(like :=)
function and(in a,b:integer):integer;infix priority=2;
--(same priority as "*")
--infix function does not allowed to change operands

(if we don't have this already ;-)

and then 

a inc b and (c+d);

We should be allowed to have infix operators,then we will be able to
add
z juliafractal c;

in any case it's not a very big advantage for readability.IMO it's
less readable,like notation without () . And i don't really need
it.But i think += without it is bad idea.

In math there are currently does not allowed to add new infix
functions to +-*/
.

Dmytry Lavrov,
http://dmytrylavrov.narod.ru

Re: += in ada

[Russ]

dmytrylavrov@fsmail.net (Dmytry Lavrov) wrote in message news:<49cbf610.0310101231.2358762a@posting.google.com>...
> 18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0310091107.6c0c3716@posting.google.com>...
> > Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote in message news:<slrnbo7afh.1rc.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no>...
> > > On 2003-10-07, Russ <18k11tm001@sneakemail.com> wrote:
> > > > Repeat after me: Augmented assignment is available and WIDELY USED in
> > > > C, C++, Java, Perl, and Python, perhaps the 5 most popular
> > > > general-purpose programming languages ever designed. Is it *possible*
> > > > that 98% of the programmers out there might know *something* that Ada
> > > > programmers don't?

> Here you're saying: let's be with masses,masses can't make mistakes.

OK, I can see how you could have misunderstand my point here, so let
me clarify.

I am *not* claiming that augmented assignment operators (":+", ":-",
":*", ":/") are good *because* 98% of programmers use them. What I am
claiming is that 98% of programmers use them *because* they are a good
idea. And I have given three good reasons why augmented assignment
operators can enhance both readability and efficiency. I won't go over
them again here because if you don't get it by now you never will.

> I'm is a beginner in ada,moving from Free Pascal(and also i can code
> in java and c) where(if FP too) += are supported, and I DON'T WANT +=
> .
> Even beginners don't want it!

This is precisely the attitude that bothers me. I spend all kinds of
time carefully explaining why the five most popular programming
languages all have augmented assignment, and all I get back is, "I
don't like it!", " I don't want it!", and "Even beginners don't want
it!" No rational reason given.

The only rational reply I have received so far is that augmented
assignment operators are too much effort to implement. Well, they
obviously weren't too much effort for C, C++, Java, Perl, and Python.
It's really too bad that Ada is so strapped for support. That obvously
doesn't bode well for the future of Ada.

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Russ wrote:

>This is precisely the attitude that bothers me. I spend all kinds of
>time carefully explaining why the five most popular programming
>languages all have augmented assignment, and all I get back is, "I
>don't like it!", " I don't want it!", and "Even beginners don't want
>it!" No rational reason given.

Oh sorry. I didn't notice that "readability" is not rational enough to
be an argument.

So let's add a little bit more irrationality? Here it goes: When I am
reading source, I read it left to right, top to bottom like a book.
Infixed augmented operator break that reading flow and that's why *I*
don't want them.

Not to mention the readability if you have the source on paper which
has all the rings from the coffee cup on it. :->


Vinzent.

Re: += in ada

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
:> > > On 2003-10-07, Russ <18k11tm001@sneakemail.com> wrote:
:> > > > Repeat after me: Augmented assignment is available and WIDELY USED in
:> > > > C, C++, Java, Perl, and Python, perhaps the 5 most popular
:> > > > general-purpose programming languages ever designed.

Interesting. What about Visual Basic? What about Turbo Pascal?

Also, with respect to the syntactic choice += etc, I think one could boil
C, Java, and Perl down to 1 language, not 3. Or is there a difference
in "+=" in these languages, from a user perspective?


: What I am
: claiming is that 98% of programmers use them *because* they are a good
: idea.

Do you have any figure telling us which of the augmented operators
are used most frequently, and in what places?
How often they are overloaded in programs, e.g. C++'s "/="?

: And I have given three good reasons why augmented assignment
: operators can enhance both readability and efficiency. I won't go over
: them again here because if you don't get it by now you never will.

`At what price', you have been asked, IIRC?

: No rational reason given.
: 
: The only rational reply I have received so far is that augmented
: assignment operators are too much effort to implement.

"Too much effort" is a wording with certain implications when
it comes to programming, right? What O(f(n)) for implementing
a consistent augmented assignment in Ada does your analysis reveal?

: Well, they
: obviously weren't too much effort for C, C++, Java, Perl, and Python.

That is actually not an argument I think, because
b/ What is the meaning of += in a non-sequential C-, or Perl-program?
c/ How do you define your own += in Java, say, such that it
   is useful for your own types?

: It's really too bad that Ada is so strapped for support. That obvously
: doesn't bode well for the future of Ada.

Interesting. So programming languages are obviously chosen because
there is some form of augmented assinment in the language?
Why do people choose Visual Basic, or Fortran, or Delphi?


Georg

Re: += in ada

[Hyman Rosen]

Georg Bauhaus wrote:
> Also, with respect to the syntactic choice += etc, I think one could boil
> C, Java, and Perl down to 1 language, not 3. Or is there a difference
> in "+=" in these languages, from a user perspective?

Java does not support user-defined operators at all.
All operators in Java are built-in only. Ditto for C.
C++ and Perl allow user-defined operators to be written
when at least one operand is a user-defined type.

> Interesting. So programming languages are obviously chosen because
> there is some form of augmented assinment in the language?
> Why do people choose Visual Basic, or Fortran, or Delphi?

Even in COBOL you could say "ADD A TO B."

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>> Interesting. So programming languages are obviously chosen because
>> there is some form of augmented assinment in the language?
>> Why do people choose Visual Basic, or Fortran, or Delphi?
>
>Even in COBOL you could say "ADD A TO B."

You can already do it in Ada, too:

|Add (A, To => B);

So, what's your point? ;-) That it is not "built-in"?


Vinzent.

Re: += in ada

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> So, what's your point? ;-) That it is not "built-in"?

My point is that "augmented assignment" is a very old
feature of programming languages. In fact, it's a basic
feature of computers, since most of them have machine
instructions which add one thing to another.

That isn't to say that I think this feature should be
added to Ada. I don't care one way or the other.

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> So, what's your point? ;-) That it is not "built-in"?
>
>My point is that "augmented assignment" is a very old
>feature of programming languages.

And my point is that Ada already has it.

It just calls it "procedure". :)

>In fact, it's a basic
>feature of computers, since most of them have machine
>instructions which add one thing to another.

You heard about "abstraction"? Ada is a high level *language*, not a
high level assembler.

The idea was to let the programmer say what it wants and let the
compiler figure out how to map that onto the target hardware, not the
C-way: figuring out how to express what we want in such a way that
most machines might understand it. Ada is even better: It still left
the option open to get down to the bare metal of the machine if this
is needed. Target hardware (do you remember the PDP-7? - I don't.)
becomes obsolete some times. :)

<flame target="interested audience" level="explicit">

Why doesn't know C shit about interrupts? Or port I/O? Or ring buffer
data structures? So basic features of some CPUs... oh well, perhaps
not at the time they designed C, I know. Bad luck if you want to do
that. But hey, it must be fucking cool, you still have
<voice mode="pissed off">'augmented assignment'</voice>.

Oh well, that's surely a pretty nifty feature you really need, just
because you can save so much time when typing it (and IMVHO: *that* is
the only true and valid argument).

</flame>

And BTW, it's a funny thing that the compiler might compile

|a += 2;

to

|   movl a,%eax
|   addl $2,%eax
|   movl %eax,a

instead of

|   addl $2,a

, isn't it? ;-P


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: += in ada

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> You heard about "abstraction"? Ada is a high level *language*, not a
> high level assembler.

But the concept of "add this to that" *is* an abstraction.

 > And BTW, it's a funny thing that the compiler might compile
 > |a += 2;
 > to
 > |   movl a,%eax
 > |   addl $2,%eax
 > |   movl %eax,a
 > instead of
 > |   addl $2,a

See? It's an abstraction, not an attempt to duplicate assembler!

> The idea was to let the programmer say what it wants and let the
> compiler figure out how to map that onto the target hardware

Exactly. And what the programmer wants is to add a value to
a variable. If I'm keeping a running total, I want to say
"add this item to the total" not "compute the sum of the
current total and this item, and replace the current total
with the new total". That's why COBOL had "ADD A TO B."

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> You heard about "abstraction"? Ada is a high level *language*, not a
>> high level assembler.
>
>But the concept of "add this to that" *is* an abstraction.

Yes, of course. But because it changes its argument (and thus the
"state of the system") it should look like a procedure, not like a
function.

>> The idea was to let the programmer say what it wants and let the
>> compiler figure out how to map that onto the target hardware
>
>Exactly. And what the programmer wants is to add a value to
>a variable.

And the programmer is allowed to say so.

>If I'm keeping a running total, I want to say
>"add this item to the total"

So why don't you want to say so?

>not "compute the sum of the
>current total and this item, and replace the current total
>with the new total".

That's exactly what how a mathematician would express it. Have you
ever seen recursive formulas (I suppose so)?
They usually look like "a_n = a_n+1 + b" and seen that way, the Ada
abstraction is *much* more like this.

>That's why COBOL had "ADD A TO B."

And that's why you abstract exactly this with "Add (A, To => B);" in
Ada and not with "B PLUS IS EQUAL TO A". :-P

Perhaps another argument, given the notation for overloading
predefined operators

|function "+" (Left : Type_1; Right : Type_2) return Type_1;

I suppose we had to add the notation for these
infix-notated-procedures, too:

|procedure "+=" (Left : in out Type_1; Right : in Type_2);

Doesn't look right to me.

But wait, let's go further. Suppose we would then suddenly want to
write a specification like this:

|procedure "+=" (Left : in Type_2; Right : in out Type_1);

an expression "a += b;" actually would probably be implemented as
adding a to _b_, not the other way around like everyone (who has a
minimal knowledge of C-like languages) would expect. And we *will* be
pretty much confused.

Now suppose a language rule that such (specially restricted)
procedures suddenly are only allowed to change their first argument
would be a little bit, well... strange, simply not logical, confusing,
...?


Vinzent.

Re: += in ada

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> ... what the programmer wants is to add a value to
> a variable. If I'm keeping a running total, I want to say
> "add this item to the total" not "compute the sum of the
> current total and this item, and replace the current total
> with the new total". That's why COBOL had "ADD A TO B."

Yes, and that's why Pascal (at least Object Pascal/Delphi) has built-in
procedures Inc and Dec. Ada differs only in that it does not see this
abstraction as important as Pascal (or C) does and therefore Ada does not make
it built-in. After all, Ada always was intented for professional use, not for
educational use (as Pascal certainly does... and even C to some degree), so
Ada designers may assume that there is no need to include in the language
standard such a simple and obvious abstraction, which every professional can
so easily device for himself, and which hardly deserves standartization.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: += in ada

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1066231159.711433@master.nyc.kbcfp.com>...
> Vinzent 'Gadget' Hoefler wrote:
> > So, what's your point? ;-) That it is not "built-in"?
> 
> My point is that "augmented assignment" is a very old
> feature of programming languages. In fact, it's a basic
> feature of computers, since most of them have machine
> instructions which add one thing to another.

Good point.

> That isn't to say that I think this feature should be
> added to Ada. I don't care one way or the other.

Fine, but I get the impression from some of your previous posts that
Ada is not your primary programming language anyway, and perhaps that
explains your apathy.

Just for fun, suppose that Ada was the *only* language you (or anyone
who works for you) could use for the rest of your life. Then would you
care if augmented assignment operators are added to Ada? Just curious.

Re: += in ada

[Marin David Condic]

Ada is the only language we use in building control systems and if it 
never got a "+=" operator, I wouldn't care. 99.999% of the time, 
whatever you might possibly get from a += operator just plain doesn't 
matter. Its so little benefit at the expense of needlessly disrupting 
the language and forcing compiler changes on people. There isn't hardly 
any food value here - and I seriously doubt it would do anything at all 
to make Ada more acceptable to the people who don't already use it.

Or we could do it the Cobol way: ADD X TO Y. Cobol is an incredibly 
popular language - maybe this would help Ada? :-)

MDC

Russ wrote:
> 
> Just for fun, suppose that Ada was the *only* language you (or anyone
> who works for you) could use for the rest of your life. Then would you
> care if augmented assignment operators are added to Ada? Just curious.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Hyman Rosen]

Russ wrote:
> Just for fun, suppose that Ada was the *only* language you (or anyone
> who works for you) could use for the rest of your life. Then would you
> care if augmented assignment operators are added to Ada? Just curious.

I might. But I would already have created a bunch of generic
procedures (AddTo, DivideInto, SubtractFrom, etc.) and would
instantiate them when their use would appear to be needed. It
would be wordier, but then if I was an Ada user, I would be
firmly convinced that this enhances readability :-)

Hmm. Ada is not my primary language. I guess those would be
Add(a, To=>b), Subtract(a, From=>b), etc. as others have said.

Re: += in ada

[Robert I. Eachus]

Hyman Rosen wrote:

> Hmm. Ada is not my primary language. I guess those would be
> Add(a, To=>b), Subtract(a, From=>b), etc. as others have said.

Actually I find I often create

procedure Inc(X: in out Integer);

I could also create procedure Dec, or add By with a default of 1, etc. 
But it just doesn't turn out to be worth the bother.  And I think that 
is the real problem with Russ's rantings.  Some where between 98% and 
all of the benefit of the extended operators in C comes from +=, and 
that from X += 1;  In Ada I write that as Inc(X); and use the same 
number of keystrokes.  True those people who prefer to write X+=1; in C 
do save two characters, but I refuse to worry about it.
-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F8F3077.60402@comcast.net>...
> Hyman Rosen wrote:
> 
> > Hmm. Ada is not my primary language. I guess those would be
> > Add(a, To=>b), Subtract(a, From=>b), etc. as others have said.
> 
> Actually I find I often create
> 
> procedure Inc(X: in out Integer);
> 
> I could also create procedure Dec, or add By with a default of 1, etc. 
> But it just doesn't turn out to be worth the bother.  And I think that 
> is the real problem with Russ's rantings.  Some where between 98% and 
> all of the benefit of the extended operators in C comes from +=, and 
> that from X += 1;  In Ada I write that as Inc(X); and use the same 
> number of keystrokes.  True those people who prefer to write X+=1; in C 
> do save two characters, but I refuse to worry about it.

Two characters? Apparently you forgot about, or don't count, having to
write "Inc" in the first place.

As I said before, I am not an Ada programmer, so perhaps you can help
me understand something. In a large program or software system of your
design, approximately how many versions of "Inc" and the like do you
have floating around just for basic scalar types? I know that Ada
allows, and in fact encourages, the use of specialized types for
everything. Do you need to write an "Inc" procedure for each type? Or
do you perhaps use generics?

Whatever the case, wouldn't it be simpler and cleaner to just use a
standard ":+" and let the compiler do it for you? Do you get paid
extra for writing code that the compiler can generate all by itself?
And how many meetings do you need to inform your programmers of your
particular procedure naming conventions when you could avoid all that
with a simple standard for the entire Ada world?

I read all sorts of discussion on this forum about the need for
standard libraries for Ada. Well, why not start at the bottom with
standard symbols for common procedures? C++ has the STL, and it also
has a standard symbol for incrementing a stupid counter. Every
C/C++/Java/Perl/Python programmer in the world is on the same page.
But Ada leaves the naming as an excercize for the programmer, and I'm
sure there are almost as many conventions as programmers. If that
somehow helps "readability", then your definition of "readability" is
not the same as mine.

Re: += in ada

[Preben Randhol]

On 2003-10-17, Russ <18k11tm001@sneakemail.com> wrote:
>
> Two characters? Apparently you forgot about, or don't count, having to
> write "Inc" in the first place.

Same number of keystrokes:

   Inc(X);
   X += 1;

Preben

Re: += in ada

[Robert I. Eachus]

Russ wrote:

> Two characters? Apparently you forgot about, or don't count, having to
> write "Inc" in the first place.

No, I didn't, I have a package I use when I am doing "serious" 
development.  I will probably post it as the root for an "Eachus" 
heirarchy here, although I have been calling it Common.  It contains Inc 
for Integer and Character, but the part I use even more than that is a 
set of TBD declarations.  These allow me to say for example:

function Do_Something(A, B: Parameters) return Integer is
begin return TBD("Do_Something"); end Do_Something;

(And yes I do add the optional name to the end automatically, I type 
pretty fast, and it is easier to always add it than to stop to think.)

Of course, now my code compiles cleanly and if I run it, the call to 
TBD, if called prints a message and raises To_Be_Done. ;-)  Very handy 
feature.

Of course, when code is "complete" I want to get rid of the with Common; 
use Common; so I will cut and paste some declarations like Inc if 
necessary to do that.  I have been thinking of splitting thing and 
having a separate package "To_Be_Done".

> As I said before, I am not an Ada programmer, so perhaps you can help
> me understand something. In a large program or software system of your
> design, approximately how many versions of "Inc" and the like do you
> have floating around just for basic scalar types? I know that Ada
> allows, and in fact encourages, the use of specialized types for
> everything. Do you need to write an "Inc" procedure for each type? Or
> do you perhaps use generics?

It may be a failure of my style, but I think it is pretty common for Ada 
programmers, things you want to increment are almost always Integers or 
a subtype of Integer.  I do have a quirk of writing some Inc calls for 
Character and other character types, but that is almost certainly due to 
my involvement with character set issues.  (Things like printing tables 
of Characters and their classification if you use a non-Latin1 character 
set via compile-time option.)

> Whatever the case, wouldn't it be simpler and cleaner to just use a
> standard ":+" and let the compiler do it for you? Do you get paid
> extra for writing code that the compiler can generate all by itself?
> And how many meetings do you need to inform your programmers of your
> particular procedure naming conventions when you could avoid all that
> with a simple standard for the entire Ada world?

I would love to replace the almost useless Character'Succ function with 
an Inc procedure in the standard, or just add Inc.  I wouldn't even mind 
if it were called Succ instead.  But ":+" is a non-starter for me and 
most Ada programmers. Same goes for Foo++; which, if anything would be 
much more acceptable to Ada programmers, and which you seem to ignore. 
(Hmmm. In fact, ++Foo; might be acceptable to most Ada programmers, and 
should be much more acceptable than Foo++; even though the pre- and 
post- semantics wouldn't apply to Ada.)

> I read all sorts of discussion on this forum about the need for
> standard libraries for Ada. Well, why not start at the bottom with
> standard symbols for common procedures? C++ has the STL, and it also
> has a standard symbol for incrementing a stupid counter. Every
> C/C++/Java/Perl/Python programmer in the world is on the same page.
> But Ada leaves the naming as an excercize for the programmer, and I'm
> sure there are almost as many conventions as programmers. If that
> somehow helps "readability", then your definition of "readability" is
> not the same as mine.

This is where you are just p***ing up a rope.  Ada programmers don't 
LIKE the implied side effects associated with += and other such 
operators in C.  You will never get anyone who does a lot of programming 
in Ada to accept it.  On the other hand for Inc(Foo); and ++Foo; there 
is one effect, and it is the intended effect, not a side effect.

There is a HUGE difference between X += 1; and X := 1; and that is what 
you are fighting. It is a readability issue.  How many times do I have 
to misread :+ as := to wipe out all the advantage from adding :+ to Ada? 
  Oh, and in C where do you most often use +=?  Right, in for loops. 
(And yes, most good C programmers use ++ more often there than +=.) But 
in Ada there is an implied increment function in: for I in Foo'Range 
loop and a decrement in for I in reverse Foo'Range; so even if it was 
available, :+ in Ada would appear a lot less frequently than += in C.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F900F35.50203@comcast.net>...
> Russ wrote:

> > I read all sorts of discussion on this forum about the need for
> > standard libraries for Ada. Well, why not start at the bottom with
> > standard symbols for common procedures? C++ has the STL, and it also
> > has a standard symbol for incrementing a stupid counter. Every
> > C/C++/Java/Perl/Python programmer in the world is on the same page.
> > But Ada leaves the naming as an excercize for the programmer, and I'm
> > sure there are almost as many conventions as programmers. If that
> > somehow helps "readability", then your definition of "readability" is
> > not the same as mine.
> 
> This is where you are just p***ing up a rope.  Ada programmers don't 
> LIKE the implied side effects associated with += and other such 
> operators in C.  You will never get anyone who does a lot of programming 
> in Ada to accept it.  On the other hand for Inc(Foo); and ++Foo; there 
> is one effect, and it is the intended effect, not a side effect.

I simply do not understand your reasoning here. How does "+=" (or
":+") have any more side effects than "Inc" or "++"? They are all just
procedures. Please give me an example where "+=" has a side effect
that "Inc" or "++" cannot have. Until you do, I think you may have
just exposed the irrationality of your objection to augmented
assignment operators.

> There is a HUGE difference between X += 1; and X := 1; and that is what 
> you are fighting. It is a readability issue.  How many times do I have 
> to misread :+ as := to wipe out all the advantage from adding :+ to Ada? 

Yes, and there is a huge difference between 100000.0 and 1000000.0
too. There is a huge difference between X := Y * 2 and X := Y + 2.
There is a huge difference between X <= Y and X >= Y. So what? I have
no trouble distinguishing between them, and I have no trouble
distinguishing between := and :+. They look as different as day and
night to me.

As I said before, I am not a professional programmer or computer
scientist. I am aerospace engineer working on future concepts for
safety critical air traffic management systems 20 years in the future.
I would like to think that Ada will be an option when the time comes
to implement my concepts, but I am losing hope.

Because my formal training is not in programming or computer science,
I have restricted my comments on Ada to relatively low-level aspects
of the language. I don't consider myself qualified to comment on more
complicated issues. However, judging by my experience here, I am
losing faith in the Ada community. If you can't get the little things
right, how in the world can you can the complicated things right? I
don't think you can, and I don't think you will.

I have read several times here that augmented assignment operators are
a "non-starter", but I have yet to read any good reason why, other
than the lack of manpower in the Ada world. That tells me that Ada is
over the hill. Yesterday's news. Ossified. Ada is a legacy language.
RIP.

Re: += in ada

[Robert I. Eachus]

Russ wrote:

> I simply do not understand your reasoning here. How does "+=" (or
> ":+") have any more side effects than "Inc" or "++"? They are all just
> procedures. Please give me an example where "+=" has a side effect
> that "Inc" or "++" cannot have. Until you do, I think you may have
> just exposed the irrationality of your objection to augmented
> assignment operators.

This is what you continue to just not get.  Either the addition is a 
side effect of the assignment, or the assignment is a side effect of the 
addition.  I don't care that you don't think that way.  My point is that 
Ada programmers think that way, and it makes += very ugly.  It may be, 
from your point of view, irrational, stupid, crazy, etc., but I don't 
care.  Nor do most Ada programmers.

> Yes, and there is a huge difference between 100000.0 and 1000000.0
> too.

Which is why Ada programmers would not write either.  We could get into 
a long discussion about breaking such literals into groups of three, 
four or even five characters.  Ada programmers would be glad to oblidge. 
  But most, if not all Ada programmers would see:

Big: constant := 100000.0;
Bigger: constant := 1000000.0;

as wrong, whereas

Big: constant := 100_000.0;
Bigger: constant := 1000_000.0;

vs:

Big: constant := 100_000.0;
Bigger: constant := 1_000_000.0;

...would be seen as a style issue--and wrong if the project had an 
agreed style in this area.

> As I said before, I am not a professional programmer or computer
> scientist. I am aerospace engineer working on future concepts for
> safety critical air traffic management systems 20 years in the future.
> I would like to think that Ada will be an option when the time comes
> to implement my concepts, but I am losing hope.
> 
> Because my formal training is not in programming or computer science,
> I have restricted my comments on Ada to relatively low-level aspects
> of the language. I don't consider myself qualified to comment on more
> complicated issues. However, judging by my experience here, I am
> losing faith in the Ada community. If you can't get the little things
> right, how in the world can you can the complicated things right? I
> don't think you can, and I don't think you will.
> 
> I have read several times here that augmented assignment operators are
> a "non-starter", but I have yet to read any good reason why, other
> than the lack of manpower in the Ada world. That tells me that Ada is
> over the hill. Yesterday's news. Ossified. Ada is a legacy language.
> RIP.

And, as I said, you still don't get it.  Ada had those arguments, lots 
of them, to boring extremes.  I remember one point where I was getting 
new draft Reference Manual chapters every few weeks, and often the 
comments on a new draft would be longer than the draft within the first 
week.  I once sent in fifty pages of comments in one email, then Mike 
Woodger outdid me by sending in a longer set of comments--all about 
commas vs. semicolons and other detailed punctuation issues in the text.

Ada has adopted a consistant style.  As you should be able to see, there 
are still arguments on the margins, like overloading To_String and 
To_Unbounded_String with unary "+", or adding Inc for integer types. 
But changing style to the extent implied by your comments would be a 
Richter scale magnitude 9.5 earthquake at the foundations of the the 
language structure.  It won't happen.  Other languages have those 
notations, Ada doesn't.  Ada allows underscores in numeric literals, 
other languages allow commas, or nothing at all.  And so on.

At a certain point, you are not changing the language, you are inventing 
a new one.  Get over it.




-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F92B607.809@comcast.net>...
> Russ wrote:
> 
> > I simply do not understand your reasoning here. How does "+=" (or
> > ":+") have any more side effects than "Inc" or "++"? They are all just
> > procedures. Please give me an example where "+=" has a side effect
> > that "Inc" or "++" cannot have. Until you do, I think you may have
> > just exposed the irrationality of your objection to augmented
> > assignment operators.
> 
> This is what you continue to just not get.  Either the addition is a 
> side effect of the assignment, or the assignment is a side effect of the 
> addition.  I don't care that you don't think that way.  My point is that 
> Ada programmers think that way, and it makes += very ugly.  It may be, 
> from your point of view, irrational, stupid, crazy, etc., but I don't 
> care.  Nor do most Ada programmers.

You said that "+=" has more side effects than "Inc" or "++", and I
challenged you for an example where "+=" has a side effect that "Inc"
or "++" cannot have. I'm still waiting for your example, and I have a
feeling I'll be waiting for quite a while.

Your main argument against "+=" is hollow. The only argument you have
left is that "Ada programmers think that way". You guys can gang up on
me all you want, but the fact is that you are the ones with the hard
heads, and your attitude is allowing a promising language to die or
languish in the shadows.

Here's a word of advice for all you young programmers out there (if
there are any here). Don't get too attached to Ada, because your job
prospects as an Ada programmer in the next 20 years will be slim to
none. No, its not just because Ada doesn't have "+=", but it *is*
because of the attitude that refuses to add it, and compares such a
minor addition to the language to a "9.5 on the Richter scale."

Congratulations, Mr. Eachus, you've won the battle. But you (and all
the other regulars on this tiny little newsgroup) are losing the war.
You are developing the perfect language that nobody (except people
named Preben) will use any more unless they are forced to maintain
legacy code to feed themselves. Ada will be the COBOL of the next
generation -- except that it won't be used nearly as much.

Re: += in ada

[Chad R. Meiners]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0310191559.5d9fa9@posting.google.com...
> You said that "+=" has more side effects than "Inc" or "++", and I
> challenged you for an example where "+=" has a side effect that "Inc"
> or "++" cannot have. I'm still waiting for your example, and I have a
> feeling I'll be waiting for quite a while.

x += y += 1;

which you cannot do with "++" or an Inc procedure.

> Here's a word of advice for all you young programmers out there (if
> there are any here). Don't get too attached to Ada, because your job
> prospects as an Ada programmer in the next 20 years will be slim to
> none. No, its not just because Ada doesn't have "+=", but it *is*
> because of the attitude that refuses to add it, and compares such a
> minor addition to the language to a "9.5 on the Richter scale."

These are all interesting perspectives from someone that has claimed that he
is not a professional programmer and that he does not know Ada.  This might
explain why you are fixated upon a little issue such as augmented assignment
but are completely unconcerned about how the Ada was designed to be a safe
and consentient language.

Now let us get back to the original problem, Russ.  You are worried that
future air traffic control software will not be written in Ada because Ada
does not have augmented assignments.  Now it seems to me that augmented
assignments is a bogus requirement for air traffic control software;
furthermore, it should not take precedence over important requirements such
as readability, and early error detection.   Anyone lobbying for augmented
assignment features over safety features should be fired if they are
developing safety critical software.

> Congratulations, Mr. Eachus, you've won the battle. But you (and all
> the other regulars on this tiny little newsgroup) are losing the war.

I assume you mean the war against ignorance ;-)  Well you can give people
knowledge, but you can't force them to understand it.

> You are developing the perfect language that nobody (except people
> named Preben) will use any more unless they are forced to maintain
> legacy code to feed themselves. Ada will be the COBOL of the next
> generation -- except that it won't be used nearly as much.

People that use Ada are people that feel safety and maintenance are
important characteristics of a programming language.

Re: += in ada

[Robert I. Eachus]

I had about decided to let this topic die a graceful death when Chad R. 
Meiners wrote:

> People that use Ada are people that feel safety and maintenance are
> important characteristics of a programming language.

I felt this is worth repeating, if only as a epitaph to this topic. 
This is what Russ kept not understanding.  Add clarity and readability 
and a lot of what we used to call the -ilities, and that is the debate 
in a nutshell.  Chad even gave a perfect riposte, to the question of 
side effects. The statement x += y += 1; is perfectly legal C, and I'll 
let Russ choose what is the effect, and what is the side effect.

But back to the -ilities.  They are the core of what Ada is meant to be. 
  No particular -ilitiy, such as maintainability or reliability is given 
primacy of purpose.  All are important.  And no one who understands Ada 
is willing to give up a piece of any of the -ilities to save keystrokes. 
  Something that improves readability at a slight cost in 
maintainability?  Let me think about it, a lot.  The same for a change 
that went the other way.  But something that gives up a little bit of 
each of the -ilities to make the code generator's job easier?  Or to 
save keystrokes?  Forget it.

-- 
                                        Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Marin David Condic]

Aside from these legitimate arguments, there is one other: Its really 
easy to succumb to the temptation to try to please everyone and end up 
with garbage as a result. I'm sure we could find a steady stream of C++ 
fans who would say "Ada would be better if only it had a "+=" operator." 
and "Ada would be better if only it used "{" and "}" instead of "begin" 
and "end"..." and "Ada would be better if only it used "*" instead of 
'Address/access..." All that amounts to saying is "Ada would be better 
if only it were the language I *really* want to use - C++"

We couldn't start changing Ada to look like C++ to win over the C++ 
fans. It would either become C++ or it would remain Ada with a bizarre 
hodge-podge syntax that would be neither Ada nor C++. In either case, 
the C++ fans still wouldn't like Ada because they'd hate its type model 
or its generics or its tasking model or something else far more profound 
than its syntax.

People have not avoided Ada over its syntax. They've avoided it for much 
bigger reasons than that. Changing the syntax would only overwork the 
compiler writers, piss off the existing users and make no new batch of 
converts as an end result.

MDC

Robert I. Eachus wrote:
> I had about decided to let this topic die a graceful death when Chad R. 
> Meiners wrote:
> 
>> People that use Ada are people that feel safety and maintenance are
>> important characteristics of a programming language.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Preben Randhol]

On 2003-10-20, Marin David Condic <nobody@noplace.com> wrote:
> People have not avoided Ada over its syntax. They've avoided it for much 
> bigger reasons than that. Changing the syntax would only overwork the 
> compiler writers, piss off the existing users and make no new batch of 
> converts as an end result.

Actually I don't think most programmers have avoided Ada, deliberately. I
find that many programmers haven't heard of it. And changing the syntax
won't help that.

Preben
-- 
This is Ada95 land. On quiet nights you can hear C programmers debug.

Re: += in ada

[Wes Groleau]

Marin David Condic wrote:
> Aside from these legitimate arguments, there is one other: Its really 
> easy to succumb to the temptation to try to please everyone and end up 
> with garbage as a result. 

Isn't that how C++ got to where it is today?

-- 
Wes Groleau

    "A man wih an experience is never
     at the mercy of a man with an argument."
                       -- Ron Allen

Re: += in ada

[Hyman Rosen]

Wes Groleau wrote:
> Isn't that how C++ got to where it is today?

Yep.

Re: += in ada

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3F93D7A5.8020801@noplace.com>...
> Aside from these legitimate arguments, there is one other: Its really 
> easy to succumb to the temptation to try to please everyone and end up 
> with garbage as a result. I'm sure we could find a steady stream of C++ 
> fans who would say "Ada would be better if only it had a "+=" operator." 
> and "Ada would be better if only it used "{" and "}" instead of "begin" 
> and "end"..." and "Ada would be better if only it used "*" instead of 
> 'Address/access..." All that amounts to saying is "Ada would be better 
> if only it were the language I *really* want to use - C++"

Well, I certainly would not be one of them. I do *not* think that "{"
is preferable to begin, and I do *not* really want to use C++. But you
and others keep repeating the same canards over and over. Once again,
"+=" is *not* just in C and C++, it is in C, C++, Java, Perl, and
Python, all of which are major modern languages. Ada is in jeopardy of
becoming a *minor* programming language.

> People have not avoided Ada over its syntax. They've avoided it for much 
> bigger reasons than that. Changing the syntax would only overwork the 
> compiler writers, piss off the existing users and make no new batch of 
> converts as an end result.

Ya, and why have they avoided it? You do *not* know the root cause of
why Ada is shunned. Let me try to illustrate a critical point for you.
You cannot necessarily tell why people shun Ada just by asking them.
Sometimes they don't even know themselves. No, they will not say that
they shun Ada because they don't like ":=", but that doesn't mean it
didn't have a subconscious effect on them.

I saw a TV program a few years ago (20/20) in which they did some
experiments. They sent short guys with strong qualifications on job
interviews, and they sent tall guys with weak qualifications to the
same interviews. Guess what happened? The tall, unqualified guys
regularly beat out the short, qualified guys! Yet, when the
interviewers were asked about it, they denied that the applicant's
height had anything to do with it! This illustrates my point that
people often do not understand their own subconscious criteria.

The fact that the 10 most popular programming languages ever designed
*all* use "=" for assignment means something, whether you choose to
ignore it or not. Just do me a favor, please. Don't patronize me when
you are the one ignoring the overwhelming objective evidence.

By the way, I apologize for the STFU remark I made the other day. But
I still resent your patronizing tone.

Re: += in ada

[Marius Amado Alves]

On Tue, 2003-10-21 at 06:37, Russ wrote:
> ... The tall, unqualified guys
> regularly beat out the short, qualified guys! Yet, when the
> interviewers were asked about it, they denied that the applicant's
> height had anything to do with it!

They were simply lying.

> The fact that the 10 most popular programming languages ever designed
> *all* use "=" for assignment

What is the top 10 again? (I suppose it doesn't include COBOL, Pascal,
Smalltalk.)

Re: += in ada

[Russ]

Marius Amado Alves <amado.alves@netcabo.pt> wrote in message news:<mailman.139.1066731062.25614.comp.lang.ada@ada-france.org>...
> On Tue, 2003-10-21 at 06:37, Russ wrote:
> > ... The tall, unqualified guys
> > regularly beat out the short, qualified guys! Yet, when the
> > interviewers were asked about it, they denied that the applicant's
> > height had anything to do with it!
> 
> They were simply lying.

I doubt that. They did not realize it was a set-up until after they
made their decisions. They thought they were actually hiring people to
work for them! Do you think they would *deliberately* hire a
substantially less qualified applicant because he is taller?

> > The fact that the 10 most popular programming languages ever designed
> > *all* use "=" for assignment
> 
> What is the top 10 again? (I suppose it doesn't include COBOL, Pascal,
> Smalltalk.)

I am using "top ten" is a historical sense, thus Fortran would be
included, for example.

Yes, it would include COBOL, and yes COBOL uses "=" for assignment (in
its "compute" statement).

Pascal was once widely used for teaching programming, but I don't
think it was ever a major language in industry (regardless of what
Borland thinks). I don't think it would be in the top ten, but I could
be wrong.

Smalltalk may be a fine language, but I seriously doubt it is in the
top ten. Then again, it uses ":=" for assignment, so how could it be?

Re: += in ada

[Preben Randhol]

On 2003-10-20, Robert I. Eachus <rieachus@comcast.net> wrote:

> And no one who understands Ada is willing to give up a piece of any of
> the -ilities to save keystrokes. 

Yes. Saving keystrokes is the text editor's job, not the programming
language.

-- 
Preben Randhol ------------- http://www.pvv.org/~randhol/vim --
                 "Vim : simply the best text editor out there."

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F937806.9080205@comcast.net>...
> I had about decided to let this topic die a graceful death when Chad R. 
> Meiners wrote:
> 
> > People that use Ada are people that feel safety and maintenance are
> > important characteristics of a programming language.
> 
> I felt this is worth repeating, if only as a epitaph to this topic. 
> This is what Russ kept not understanding.  Add clarity and readability 
> and a lot of what we used to call the -ilities, and that is the debate 
> in a nutshell.  Chad even gave a perfect riposte, to the question of 
> side effects. The statement x += y += 1; is perfectly legal C, and I'll 
> let Russ choose what is the effect, and what is the side effect.

I'll tell you exactly what the effect is: a compile error. And I must
say that I am a bit surprised that this is not obvious to you. "+="
would be a procedure, and my understanding of procedures in Ada is
that they do *not* return a value.

Let's consider either possibility for operator precedence:

    x += ( y += 1 );
or
    ( x += y ) += 1;

The first grouping will not compile because the expression in parens
returns no value. The second grouping will not compile because, as far
as I know, a procedure cannot be an lhs (because it cannot return a
reference, as in C++). Am I missing something here?

Re: += in ada

[Lutz Donnerhacke]

* Russ wrote:
> "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F937806.9080205@comcast.net>...
>> in a nutshell.  Chad even gave a perfect riposte, to the question of 
>> side effects. The statement x += y += 1; is perfectly legal C, and I'll 
>> let Russ choose what is the effect, and what is the side effect.
>
> I'll tell you exactly what the effect is: a compile error.

You should learn even C before ranting any further.
$ cat >t.c
#include <stdio.h>
#include <stdlib.h>

int main(void) {
   int a = 1, b = 2;

   printf("a = %d\nb = %d\n", a, b);
   printf("Result: %d\n", a += b += 1);
   printf("a = %d\nb = %d\n", a, b);

   return EXIT_SUCCESS;
}
$ make t
cc     t.c   -o t
$ ./t
a = 1
b = 2
Result: 4
a = 4
b = 3
$ _

> And I must say that I am a bit surprised that this is not obvious to you.

Your attitude does not match you knowledge. That's not funny.

> "+=" would be a procedure, and my understanding of procedures in Ada is
> that they do *not* return a value.

Yep. But we talked about C in this paragraph.

> Am I missing something here?

Yes: The language context.

Re: += in ada

[Russ]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbpaaju.ns.lutz@taranis.iks-jena.de>...
> * Russ wrote:
> > "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F937806.9080205@comcast.net>...
> >> in a nutshell.  Chad even gave a perfect riposte, to the question of 
> >> side effects. The statement x += y += 1; is perfectly legal C, and I'll 
> >> let Russ choose what is the effect, and what is the side effect.
> >
> > I'll tell you exactly what the effect is: a compile error.
> 
> You should learn even C before ranting any further.

I was programming a state-of-the-art experimental real-time precision
landing system in C++ 10 years ago.

> > And I must say that I am a bit surprised that this is not obvious to you.
> 
> Your attitude does not match you knowledge. That's not funny.
> 
> > "+=" would be a procedure, and my understanding of procedures in Ada is
> > that they do *not* return a value.
> 
> Yep. But we talked about C in this paragraph.

No, I wrote exclusively about Ada, except to point out that "x += y +=
1" compiles in C but would not in Ada (if Ada had "+="). And that
rendered Mr. Eachus's point irrelevant to Ada. I did *not* claim that
"x += y += 1"  would not compile in C. I do have your permission to
discuss Ada here on comp.lang.ada, do I not?

> > Am I missing something here?
> 
> Yes: The language context.

You're the one missing that.

Look, folks, I'm trying my best to be polite, but you have to agree
that this guy is seriously confused to say the least. And he seems to
have some kind of personal animosity toward me. That's bad for your
emotional health, dude.

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Russ wrote:

> And he seems to
>have some kind of personal animosity toward me. That's bad for your
>emotional health, dude.

Your talking to Lutz? Funny.


Vinzent.

Re: += in ada

[Lutz Donnerhacke]

* Russ wrote:
> Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbpaaju.ns.lutz@taranis.iks-jena.de>...
>> * Russ wrote:
>> > "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F937806.9080205@comcast.net>...
>> >> in a nutshell.  Chad even gave a perfect riposte, to the question of 
>> >> side effects. The statement x += y += 1; is perfectly legal C, and I'll 
>> >> let Russ choose what is the effect, and what is the side effect.
>> >
>> > I'll tell you exactly what the effect is: a compile error.
>> 
>> You should learn even C before ranting any further.
> 
> I was programming a state-of-the-art experimental real-time precision
> landing system in C++ 10 years ago.

You never learned the difference between effect and side effect in those
years? Your information reception ability seems very limited.

>> Yep. But we talked about C in this paragraph.
>
> No, I wrote exclusively about Ada,

Yes, you moved to just another discussion place in order to refuse to answer
a clear question. That's bad discussion style.

> rendered Mr. Eachus's point irrelevant to Ada. I did *not* claim that
> "x += y += 1"  would not compile in C. I do have your permission to
> discuss Ada here on comp.lang.ada, do I not?

You was asked to define the effect and the side effect in a legal C statement.
Prefering procedures to implement it in Ada does not answer this question.

> Look, folks, I'm trying my best to be polite, but you have to agree
> that this guy is seriously confused to say the least. And he seems to
> have some kind of personal animosity toward me. That's bad for your
> emotional health, dude.

Fuck off.

Re: += in ada

[Russ]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbpchsk.oa.lutz@taranis.iks-jena.de>...
> * Russ wrote:
> > Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbpaaju.ns.lutz@taranis.iks-jena.de>...
> >> * Russ wrote:
> >> > "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F937806.9080205@comcast.net>...
> >> >> in a nutshell.  Chad even gave a perfect riposte, to the question of 
> >> >> side effects. The statement x += y += 1; is perfectly legal C, and I'll 
> >> >> let Russ choose what is the effect, and what is the side effect.
> >> >
> >> > I'll tell you exactly what the effect is: a compile error.
> >> 
> >> You should learn even C before ranting any further.
> > 
> > I was programming a state-of-the-art experimental real-time precision
> > landing system in C++ 10 years ago.
> 
> You never learned the difference between effect and side effect in those
> years? Your information reception ability seems very limited.

For the record, I scored in the top 1% of the math section of the
Graduate Records Exam, and I scored in the top 12% of the verbal
section. (The GRE is the test that engineers take to get into graduate
school.) I don't normally brag about things like that, but I don't see
why I should have to keep it a secret when my "information reception
ability" is challenged by a mental midget on a public forum.  You
don't know what you're talking about.

> >> Yep. But we talked about C in this paragraph.
> >
> > No, I wrote exclusively about Ada,
> 
> Yes, you moved to just another discussion place in order to refuse to answer
> a clear question. That's bad discussion style.
> 
> > rendered Mr. Eachus's point irrelevant to Ada. I did *not* claim that
> > "x += y += 1"  would not compile in C. I do have your permission to
> > discuss Ada here on comp.lang.ada, do I not?
> 
> You was asked to define the effect and the side effect in a legal C statement.
> Prefering procedures to implement it in Ada does not answer this question.
> 
> > Look, folks, I'm trying my best to be polite, but you have to agree
> > that this guy is seriously confused to say the least. And he seems to
> > have some kind of personal animosity toward me. That's bad for your
> > emotional health, dude.
> 
> Fuck off.

That's the most intelligent thing you've said yet, dude. If you're
representative of the level of intelligence on this forum, then that
explains the reception I have received. Fortunately for the others
here, I don't think you are.

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Russ wrote:

>That's the most intelligent thing you've said yet, dude. If you're
>representative of the level of intelligence on this forum, then that
>explains the reception I have received.

<URL:http://www.amishrakefight.org/gfy/index.shtml>

Sorry, folks. But enough is enough.


Vinzent.

Re: + in ada

[Russ]

Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bn6kos$u4o1s$1@ID-175126.news.uni-berlin.de>...
> Russ wrote:
> 
> >That's the most intelligent thing you've said yet, dude. If you're
> >representative of the level of intelligence on this forum, then that
> >explains the reception I have received.

I just love how you cut out the line I was replying to. Oh, it wasn't
relevant, I guess. Then you cut out the last sentence of my paragraph.
Nice trick. Shit, you should be writing for the New York Times.

> Sorry, folks. But enough is enough.

It sure is, 'Gadget'.

Re: += in ada

[sk]

Russ <18k11tm001@sneakemail.com>:

 > For the record, I scored in the top 1% of the math section of the
 > Graduate Records Exam, and I scored in the top 12% of the verbal

Dude, I would demand a refund if I was you. Any math requirements
must be very weak that passes some one in the top 1% with your grasp
on statistical sample sets :-)

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[Vinzent 'Gadget' Hoefler]

sk wrote:

>Dude, I would demand a refund if I was you. Any math requirements
>must be very weak that passes some one in the top 1% with your grasp
>on statistical sample sets :-)

Just have a look at it: <URL:ftp://ftp.ets.org/pub/gre/Math.pdf>.

I guess, the hardest part is the calculation of the scores. :->


Vinzent.

Re: += in ada

[Russ]

sk <noname@myob.com> wrote in message news:<mailman.178.1066849665.25614.comp.lang.ada@ada-france.org>...
> Russ <18k11tm001@sneakemail.com>:
> 
>  > For the record, I scored in the top 1% of the math section of the
>  > Graduate Records Exam, and I scored in the top 12% of the verbal
> 
> Dude, I would demand a refund if I was you. Any math requirements
> must be very weak that passes some one in the top 1% with your grasp
> on statistical sample sets :-)

That's funny, I darn near aced my undergrad intro probability and
statistics class. That was a long time ago, and it *is* possible that
I need a little review, but apparently I did have a "grasp" of
statistical sample sets at one time. :-)

Re: += in ada

[sk]

Russ <18k11tm001@sneakemail.com>
 > ...

Cheers, its been fun, but time to move on.

  o o
   |
  \_/

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[Russ]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbpchsk.oa.lutz@taranis.iks-jena.de>...
> * Russ wrote:
> > Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbpaaju.ns.lutz@taranis.iks-jena.de>...
> >> * Russ wrote:
> >> > "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F937806.9080205@comcast.net>...
> >> >> in a nutshell.  Chad even gave a perfect riposte, to the question of 
> >> >> side effects. The statement x += y += 1; is perfectly legal C, and I'll 
> >> >> let Russ choose what is the effect, and what is the side effect.
> >> >
> >> > I'll tell you exactly what the effect is: a compile error.
> >> 
> >> You should learn even C before ranting any further.
> > 
> > I was programming a state-of-the-art experimental real-time precision
> > landing system in C++ 10 years ago.
> 
> You never learned the difference between effect and side effect in those
> years? Your information reception ability seems very limited.

OK, let me reply to this post for a second time, this time without the
personal stuff. You're probably an intelligent fellow, and even though
you insulted me first, I was out of line to refer to you as a "mental
midget" in my first reply.

As we all know, functions in C and C++ can modify their arguments
*and* return values. Ada, on the other hand, distinguishes between
functions and procedures. In Ada, functions can return something but
cannot modify their arguments, whereas procedures can modify (some of)
their arguments but cannot return anything.

In C and C++, the data returned by a function is referred to as its
"effect", and the modification of any arguments is referred to as its
"side effect." In Ada, however, this jargon is unnecessary and
misleading, unless you want to claim that a procedure has "no effect."
Pedants might insist on such misleading jargon, but they are not using
standard English.

Getting back to "+=". In C/C++, the so-called "effect" of "+=" for
built-in types is to return a reference. For user-defined types, the
"effect" depends on whether the programmer decided to return a
reference, in which case the "effect" is to return a reference. The
actual incrementation of the argument is technically a "side effect."
Is that what you wanted to hear?

As I said, however, this jargon does not really apply to Ada. In Ada,
the effect (in the standard English sense) of "+=" (or ":+") would be
to increment the argument. Only if you insist on applying the
disfunctional jargon of C/C++ functions can this be considered a "side
effect".

And that is why Mr. Eachus's concern about "x += y += 1" is completely
and utterly irrelevant to Ada. It's nothing more than a red herring.

Did you really think I didn't know this? Give me a break!

Re: += in ada

[Wes Groleau]

Russ wrote:
> In C and C++, the data returned by a function is referred to as its
> "effect", and the modification of any arguments is referred to as its
> "side effect." In Ada, however, this jargon is unnecessary and
> misleading, unless you want to claim that a procedure has "no effect."

In Ada, the modifying of anything other than the obvious
is called a side-effect.

-- 
Wes Groleau

  Guidelines for judging others:

  1. Don't attribute to malice that which
     can be adequately explained by stupidity.

  2. Don't attribute to stupidity that which
     can be adequately explained by ignorance.

  3. Don't attribute to ignorance that which
     can be adequately explained by misunderstanding.

Re: += in ada

[Preben Randhol]

On 2003-10-22, Russ <18k11tm001@sneakemail.com> wrote:
>
> Look, folks, I'm trying my best to be polite, but you have to agree
> that this guy is seriously confused to say the least. And he seems to
> have some kind of personal animosity toward me. That's bad for your
> emotional health, dude.

I cannot say I agree at all. As to animosity I don't see that anywhere.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: += in ada

[Russ]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbpaaju.ns.lutz@taranis.iks-jena.de>...
> * Russ wrote:
> > "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F937806.9080205@comcast.net>...
> >> in a nutshell.  Chad even gave a perfect riposte, to the question of 
> >> side effects. The statement x += y += 1; is perfectly legal C, and I'll 
> >> let Russ choose what is the effect, and what is the side effect.
> >
> > I'll tell you exactly what the effect is: a compile error.
> 
> You should learn even C before ranting any further.

I was programming experimantal real-time precision landing systems in
C++ 10 years ago.

> > And I must say that I am a bit surprised that this is not obvious to you.
> 
> Your attitude does not match you knowledge. That's not funny.
> 
> > "+=" would be a procedure, and my understanding of procedures in Ada is
> > that they do *not* return a value.
> 
> Yep. But we talked about C in this paragraph.

No, I wrote exclusively about Ada, except to point out that "x += y +=
1" compiles in C but not in Ada. And that renders Mr. Eachus's point
irrelevant to Ada. I did *not* claim that "x += y += 1"  would not
compile in C. I do have your permission to discuss Ada here on
comp.lang.ada, do I not?

> > Am I missing something here?
> 
> Yes: The language context.

Look, folks, I'm trying my best to be polite, but you have to agree
that this guy is seriously confused to say the least. And he seems to
have some kind of personal animosity toward me. That's bad for your
emotional health, dude.

Re: += in ada

[Robert I. Eachus]

Russ wrote:

> I'll tell you exactly what the effect is: a compile error. And I must
> say that I am a bit surprised that this is not obvious to you. "+="
> would be a procedure, and my understanding of procedures in Ada is
> that they do *not* return a value.

Correct, IN ADA procedures do not return a value.

> Let's consider either possibility for operator precedence:
> 
>     x += ( y += 1 );
> or
>     ( x += y ) += 1;
> 
> The first grouping will not compile because the expression in parens
> returns no value. The second grouping will not compile because, as far
> as I know, a procedure cannot be an lhs (because it cannot return a
> reference, as in C++). Am I missing something here?

Yes. I understand the C (or C++) meaning perfectly.  But when you 
blithely talk about how Ada does not have augmented assignment and 
should, you may know perfectly well what you have in mind, but the ARG 
has got to understand things in gory detail to change the language.

To be blunt, in C, there are two operations: creating a value and an 
assignment.  All we are asking is that you define which is the effect, 
and which is the side effect.  You clearly don't answer because you 
don't understand the problem.  Assignment is special in Ada, very 
special.  It is not a value returning function or procedure.  It is a 
well defined sequence of events, one of which is the assignment 
operation.  Go read the ARM, or better AARM clause 5.2 headed Assignment 
Statements: http://www.adaic.org/standards/95aarm/html/AA-5-2.html.

Now, try to draft out a similar definition of what you want.  It can't 
be done, at least not based on what you have said here.  You clearly 
don't think that X :+ 1; (or whatever the final notation would be) is 
equivalent to X := X + 1;  You clearly want X evaluated ONCE, and for no 
temporaries to be involved.  From that I have to conclude that, if X is 
of a non-scalar type, such as an array--you have mentioned using this 
notation for vectors--assignment happens on a component by component 
basis.  Therefore if an exception occurs when evaluating the RHS, the 
value of the LHS can be inconsistant.  Fair enough, Ada 95 makes it 
easier to discuss such things.  But you had better clearly define which 
invariants hold, and which do not.

To my thinking the issue of exceptions when evaluating the LHS are the 
killer.  Clearly, you need the (original) value of X to evaluate the 
RHS, so that evaluation must come before any assignment operations, and 
before the addition operation.  But what if the value of X + 1 is 
inconsistant with X?  As a simple example, when X is an Integer, and X = 
Integer'Last, where do you expect the constraint check?  It can't happen 
  when you evaluate X, because that has to precede the evaluation of X + 
1.  So maybe you evaluate X twice?  Arrrggh!  We have completed the 
problematical loop.

Incidently, the procedural notation Inc(X); is well defined in ARM 
6.4.1.  But notice that there are explictly two cases.  If X is passed 
by value, there are two explicit assignment operations.  If X is passed 
by reference, there is a view conversion, and any assignment operations 
are distributed through the body of Inc.

You can now see, I hope, why I have been trying to convince you that 
adding this "simple" notation to Ada is far from simple.  On the other 
hand, Inc(X); or X++; or ++X; or whatever notation you choose is much, 
much simpler to add.  You (Russ) don't seem to be satisfied with that, 
and refuse to define what it is that Inc(X); lacks that is vital.


-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F953687.9070406@comcast.net>...
> Russ wrote:
> 
> > I'll tell you exactly what the effect is: a compile error. And I must
> > say that I am a bit surprised that this is not obvious to you. "+="
> > would be a procedure, and my understanding of procedures in Ada is
> > that they do *not* return a value.
> 
> Correct, IN ADA procedures do not return a value.
> 
> > Let's consider either possibility for operator precedence:
> > 
> >     x += ( y += 1 );
> > or
> >     ( x += y ) += 1;
> > 
> > The first grouping will not compile because the expression in parens
> > returns no value. The second grouping will not compile because, as far
> > as I know, a procedure cannot be an lhs (because it cannot return a
> > reference, as in C++). Am I missing something here?
> 
> Yes. I understand the C (or C++) meaning perfectly.  But when you 
> blithely talk about how Ada does not have augmented assignment and 
> should, you may know perfectly well what you have in mind, but the ARG 
> has got to understand things in gory detail to change the language.

I think "+=" or ":+" should be exactly equivalent to a procedure call.
Nothing more. Nothing less. A procedure does not return anything, and
neither should "+=". Sorry if that was not clear, but I really don't
understand why it wasn't. Did I ever suggest that "+=" should be like
a C function, with side effects *and* returning a value? I certainly
don't recall suggesting anything like that. If I had, then your
objections would have had some merit, but I did not.

Re: += in ada

[Robert I. Eachus]

Russ wrote:

> I think "+=" or ":+" should be exactly equivalent to a procedure call.
> Nothing more. Nothing less. A procedure does not return anything, and
> neither should "+=". Sorry if that was not clear, but I really don't
> understand why it wasn't. Did I ever suggest that "+=" should be like
> a C function, with side effects *and* returning a value? I certainly
> don't recall suggesting anything like that. If I had, then your
> objections would have had some merit, but I did not.

I agree, but then why have we had this huge, huge snitfit discussion? 
Change the topic to a desire to be able to have procedures named "+=", 
and you might generate some discussion or you might not.  Again it won't 
happen, but it won't be waving an emotional red flag.

I could probably go back and pick out a dozen posts where you swore that 
it was the assignment side effect that you wanted in Ada, but who cares. 
  Remember, the procedural version will have three assignment 
operations, two of which can be optimized away.  (For Inc(X), assign 
actual to formal, assign new value to formal, return formal to actual.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F96DF31.5040501@comcast.net>...
> Russ wrote:
> 
> > I think "+=" or ":+" should be exactly equivalent to a procedure call.
> > Nothing more. Nothing less. A procedure does not return anything, and
> > neither should "+=". Sorry if that was not clear, but I really don't
> > understand why it wasn't. Did I ever suggest that "+=" should be like
> > a C function, with side effects *and* returning a value? I certainly
> > don't recall suggesting anything like that. If I had, then your
> > objections would have had some merit, but I did not.
> 
> I agree, but then why have we had this huge, huge snitfit discussion? 
> Change the topic to a desire to be able to have procedures named "+=", 
> and you might generate some discussion or you might not.  Again it won't 
> happen, but it won't be waving an emotional red flag.

Well, I'm glad we finally have that cleared up.

> I could probably go back and pick out a dozen posts where you swore that 
> it was the assignment side effect that you wanted in Ada, but who cares.

I still don't understand where you got that impression. For overloaded
"+=", I don't see how it could be anything other than a procedure. On
the other hand, for built-in types such as integer and float (and all
the scalar types derived from them), I would expect "+=" to be
automatically available. It would be silly to require the programmer
to define all those. I hope that is clear too.

Re: += in ada

[Robert I. Eachus]

Russ wrote:

> I still don't understand where you got that impression. For overloaded
> "+=", I don't see how it could be anything other than a procedure.

All that discussion about how A += 1 is more efficient than A := A + 1;
The procedural version is theoretically significantly less efficient 
than A := A + 1; although most compilers will, when asked, do the 
inlining that makes it exactly equivalent.  If you think that A += 1 is 
more efficient you are talking about augmented assignment.  (Assignment 
with the addition as a side-effect.)  As I showed, in Ada if you try to 
generalize that to cover all cases, there are insoluble problems.

> On the other hand, for built-in types such as integer and float (and all
> the scalar types derived from them), I would expect "+=" to be
> automatically available. It would be silly to require the programmer
> to define all those. I hope that is clear too.

If you check the tread carefully, you will find articles where I and at 
least one other ARG member discussed adding Inc as a predefined 
operation for Integer types.  Several ARG members favor it, others think 
it is unnecessary.  We could also discuss whether there should be one 
procedure with a default parameter:

procedure Inc (L: in out Integer; R: in Integer := 1);

or two separate versions.  Personally I think the one parameter version 
is enough.

Of course, the predefined operation would only be available for 
predefined Integer types.  But we would probably have to consider 
whether it should be supported for other language defined types and if 
so how.  Take System.Address for example.  This "extra" overhead of any 
language change is one reason that the ARG seems so conservative.  In 
private discussions, some of the language changes considered look pretty 
revolutionary.  If the idea multiplies in scope, then it is usually 
discarded.

As a horrible example, AI-2 and AI-7 from the Ada 83 days were seemingly 
simple issues that multiplied out of control.  I remember one (back then 
LMC) meeting where  AI-2 and AI-7 plus AIs that were separated out of 
them occupied one entire volume of maybe 200 pages, and the other AIs to 
be discussed were a second volume.  As I recall we found a "simple" 
solution to AI-7.  It  basically left when a certain constraint check 
was performed undefined, but required the check. All the implementors 
who were following the discussion knew that for the problem cases there 
was only one "natural" place to do the check. For the rest we didn't 
care which of the natural places it was easiest for the compiler to the 
check.

Back to Inc. If there was sufficient demand from users, I am sure Inc 
would be added in the revision currently in progress.  However, I feel 
that there are a number of more important language changes that are "on 
the bubble" and may not make the cut due to limitations on how big a 
change we can make.  The really hard question is does this discussion 
indicate a groundswell of user support for Inc, a lot of opposition to 
it, or just a lot of idle discussion.

Notice that there are several major changes that almost certainly will 
make it in, and at least one that is "iffy."  Adding Inc would be a 
minor change.  Adding ++ would be a significant change, and augmented 
assignment would be a huge change, if we could figure out how to make it 
work.

-- 
                                       Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Peter Hermann]

Robert I. Eachus <rieachus@comcast.net> wrote:
> Back to Inc. If there was sufficient demand from users, I am sure Inc 

I would like to see serious voting procedures
(not those, where some people
 [who want thursday as the first day of the week]
 may hit the send-key 1000 times)
being considered by the ARG.

For my part e.g., I am against superfluous extensions like
INC, +=, ++ and the like.
(BTW, I would roll my own INC when really needed)

Keep my Ada language as simple as possible:
as few rules as possible is the secret of success.
This having said as an experienced Fortraner:
marched 3 days underwater and still dusty.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: += in ada

[Marius Amado Alves]

On Fri, 2003-10-24 at 09:15, Peter Hermann wrote:
> For my part e.g., I am against superfluous extensions like
> INC, +=, ++ and the like.

I have a strong feeling that this is a majority vote.

> Keep my Ada language as simple as possible:
> as few rules as possible is the secret of success.

Exactly!

Re: += in ada

[Pascal Obry]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> > Keep my Ada language as simple as possible:
> > as few rules as possible is the secret of success.
> 
> Exactly!

100% ok too.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: += in ada

[Marin David Condic]

Now there's a useful thing to come out of this discussion: Maybe the ARG 
ought to have a web page on the SIGAda site with some means of 
conducting a straw-poll on various language issues so that they could 
get some feedback from general users as to what they want to see. It has 
problems - preventing multiple voting, the fact that it is a 
self-selecting group so zealots for some feature will dominate, etc. But 
it might be a way of at least getting a read on what the market wants.

MDC


Peter Hermann wrote:
> 
> I would like to see serious voting procedures
> (not those, where some people
>  [who want thursday as the first day of the week]
>  may hit the send-key 1000 times)
> being considered by the ARG.
> 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: += in ada

[Russ]

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote in message news:<bnaqin$519$1@news.uni-stuttgart.de>...

> For my part e.g., I am against superfluous extensions like
> INC, +=, ++ and the like.
> (BTW, I would roll my own INC when really needed)

Ya, and do you roll your own "sqrt" too? Something as simple and basic
as incrementing a variable is not something that you should have to
"roll your own."

> Keep my Ada language as simple as possible:
> as few rules as possible is the secret of success.

Then why in the world aren't you using C? It's one hell of a lot
simpler than Ada, that's for sure!

With all due respect, I think your attitude is all too common here on
this forum: "I'm used to doing it a certain way, and I'll be damned if
I'll accept a simpler way."

"Rolling your own" increment procedure is *not* as simple as getting
one for free, so please refrain from rationalizing your irrationality
in the name of simplicity. You're giving "simplicity a bad name.

Re: += in ada

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<3F97E1D8.1020509@comcast.net>...
> Russ wrote:
> 
> > I still don't understand where you got that impression. For overloaded
> > "+=", I don't see how it could be anything other than a procedure.
> 
> All that discussion about how A += 1 is more efficient than A := A + 1;

I never said anything about the efficiency of += for scalars. I only
mentioned the efficiency advantage for vector and matrix operations.

> The procedural version is theoretically significantly less efficient 
> than A := A + 1; although most compilers will, when asked, do the 
> inlining that makes it exactly equivalent.  If you think that A += 1 is 
> more efficient you are talking about augmented assignment.  (Assignment 
> with the addition as a side-effect.)  As I showed, in Ada if you try to 
> generalize that to cover all cases, there are insoluble problems.
> 
> > On the other hand, for built-in types such as integer and float (and all
> > the scalar types derived from them), I would expect "+=" to be
> > automatically available. It would be silly to require the programmer
> > to define all those. I hope that is clear too.
> 
> If you check the tread carefully, you will find articles where I and at 
> least one other ARG member discussed adding Inc as a predefined 
> operation for Integer types.  Several ARG members favor it, others think 
> it is unnecessary.  We could also discuss whether there should be one 
> procedure with a default parameter:
> 
> procedure Inc (L: in out Integer; R: in Integer := 1);
> 
> or two separate versions.  Personally I think the one parameter version 
> is enough.

And I pointed out that "Inc" is fine for incrementing scalars, but
"+=" (or ":+")  is also good notation for vectors and matrices, as
well as other non-scalar types. It kills two birds with one stone.

Re: += in ada

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> Yes, and there is a huge difference between 100000.0 and 1000000.0
> too. There is a huge difference between X := Y * 2 and X := Y + 2.
> There is a huge difference between X <= Y and X >= Y. So what? I have
> no trouble distinguishing between them, and I have no trouble
> distinguishing between := and :+. They look as different as day and
> night to me.

I agree that X <= Y and X >= Y can be distinguished easily.
But 100000.0 and 1000000.0?  They look almost the same to me.
A good Ada programmer would write 100_000.0 and 1_000_000.0.
In C (etc), you can't do that.

I still don't get what you think is so important about these increment
operators.

It would certainly be convenient if there were a built-in way to
increment a variable without writing the variable name twice,
especially when the variable name is something complicated like
A[I].C.all.  Is that what you're getting at?

Or do you insist that "A[I].C.all :+ 1" or "A[I].C.all += 1" is somehow
much more readable than "Inc(A[I].C.all)"?  Or, in pseudo-COBOL,
"Add 1 to A[I].C.all"?

What about the fact that += in C can have side effects?  That is, you
can say "while (x += 7)...", using both the *result* of +=, and its
effect of addition.  I consider that bad.  Do you?

The best solution to this, in my opinion, would be to allow one to
write:

    procedure Inc(X: in out Root_Integer'Class);

This would require that the type Root_Integer (from which all integer
types are ultimately derived, in Ada) to be nameable, and it would
require the class of all such types to be nameable via 'Class.

Such a facility would be quite powerful and quite useful.
And of course Inc could easily be predefined.
And some folks might prefer it called by infix ":+" or some such
(not me).

What I don't get, though, is why you think such notations are so
*important*.  Yes, C has a nice notation +=.  Yes, many languages have
inherited that notation.  So what?  It's just plain silly to suggest
that this notation is responsible for those languages' popularity,
or that the lack of such notations leads inevitably to the demise of
Ada.

I do agree with you that it would be nice to have a notation for
incrementing a variable without naming that variable twice.
And I do agree with you that "procedure Inc" is not a good solution
(in current Ada) because it requires a separate Inc procedure for
every integer type.

- Bob

Re: += in ada

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccwub0dddq.fsf@shell01.TheWorld.com>...
> 18k11tm001@sneakemail.com (Russ) writes:

> I still don't get what you think is so important about these increment
> operators.

I admit that I'm probably making too much of them, and I hereby
apologize to everyone for my rudeness. They just seem like a good idea
to me for several reasons, and I am a bit obsessive/compulsive, so I
have a hard time letting it go.

> It would certainly be convenient if there were a built-in way to
> increment a variable without writing the variable name twice,
> especially when the variable name is something complicated like
> A[I].C.all.  Is that what you're getting at?

That's part of it.

> Or do you insist that "A[I].C.all :+ 1" or "A[I].C.all += 1" is somehow
> much more readable than "Inc(A[I].C.all)"?  Or, in pseudo-COBOL,
> "Add 1 to A[I].C.all"?

I think there should be one standard that can be overloaded for
user-defined types. I think ":+" is a good candidate for that
standard, but "Inc" would do, I suppose (with a default argument of
1). Unfortunately, "Inc(A,B)" for vector matrix addition leaves a lot
to be desired. The nice thing about "+=" or ":+" is that they look
right for both integers and matrices.

> What about the fact that += in C can have side effects?  That is, you
> can say "while (x += 7)...", using both the *result* of +=, and its
> effect of addition.  I consider that bad.  Do you?

Yes, I do, but it would not be an issue in Ada because "+=" or ":+"
would be a procedure, and as such it wouldn't return a value. So the
example you give above would not be valid.

> The best solution to this, in my opinion, would be to allow one to
> write:
> 
>     procedure Inc(X: in out Root_Integer'Class);
> 
> This would require that the type Root_Integer (from which all integer
> types are ultimately derived, in Ada) to be nameable, and it would
> require the class of all such types to be nameable via 'Class.
> 
> Such a facility would be quite powerful and quite useful.
> And of course Inc could easily be predefined.
> And some folks might prefer it called by infix ":+" or some such
> (not me).

As I said, ":+" is more versatile. It applies both to integer
incrementation *and* vector/matrix addition.

> What I don't get, though, is why you think such notations are so
> *important*.  Yes, C has a nice notation +=.  Yes, many languages have
> inherited that notation.  So what?  It's just plain silly to suggest
> that this notation is responsible for those languages' popularity,
> or that the lack of such notations leads inevitably to the demise of
> Ada.

At some point one must ask *why* Ada is so unpopular, despite the fact
that the DoD forced its use on a massive scale. Yes, the DoD mandate
created some resentment, but if Ada is really so good, those who
adopted it under duress should have eventually learned to appreciate
it. Many did, I realize, but why are so many of them now rushing to
throw off the yoke?

Yes, I realize that the issue is complex and many "higher-level"
problems exist, such as lack of standard libraries, development tools,
etc. But then you have to ask why those problems developed in the
first place. I just think that the root cause of Ada's lack of
popularity, when you get right down to it, is the awkward syntax,
notably ":=", and perhaps to a lesser extent the lack of "+=" type
operators.

Can I prove this? No, but I have a truckload of circumstantial
evidence for it. I've been over this before. Think of the most popular
languages in existence: C, C++, Java, Perl, Python, Fortran, Basic,
COBOL, even Matlab and Mathematica. Every one of them uses "=" for
assigment. Now name one wildly popular language that does *not* use
"=" for assignment. You can't do it. And no, Pascal and Modula are not
what I call wildly popular.

I realize that standard Ada is stuck with ":=", of course. However, I
have developed a relatively simple pre-processor that effectively
implements a dialect of Ada that uses "=". I call it "MyAda". I also
have the inverse pre-processor, so I can go in both directions. With a
few additional utilities, it should be possible for a member of an Ada
devepment team to use MyAda without anyone else on the team ever even
knowing. I realize that this is a long shot, but as I said, I am a bit
obsessive/compulsive.

> I do agree with you that it would be nice to have a notation for
> incrementing a variable without naming that variable twice.
> And I do agree with you that "procedure Inc" is not a good solution
> (in current Ada) because it requires a separate Inc procedure for
> every integer type.

Thanks for acknowledging that.

Re: += in ada

[Preben Randhol]

On 2003-10-20, Russ <18k11tm001@sneakemail.com> wrote:
> I admit that I'm probably making too much of them, and I hereby
> apologize to everyone for my rudeness. They just seem like a good idea
> to me for several reasons, and I am a bit obsessive/compulsive, so I
> have a hard time letting it go.

Apology accepted for my part. Remember: Resistance is futile ;-) *Kidding* 

I remember first time I looked at Ada 95 I didn't like the syntax. But
as soon as I tried Ada I saw that the syntax is tenfolds better than C
and its derivatives. It is readable and you don't have to mull for hours
over a page to find all the gotchas due to the hopeless ++i and i++,
possible assignments inside if or for statement of a ; ending an if
statement prematurely.

Preben
-- 
Good programmers do mistakes too!

Re: += in ada

[Robert I. Eachus]

Russ wrote:

> At some point one must ask *why* Ada is so unpopular, despite the fact
> that the DoD forced its use on a massive scale. Yes, the DoD mandate
> created some resentment, but if Ada is really so good, those who
> adopted it under duress should have eventually learned to appreciate
> it. Many did, I realize, but why are so many of them now rushing to
> throw off the yoke?

I think that Robert Dewar hit the nail on the head many years ago.  In 
one of his Computer Science classes he asked the students how many 
enjoyed debugging.  A large majority raised their hands.  That is the 
problem.

I detest debugging.  In fact detest is probably to mild a word.  So I 
love Ada.  When I was at Honeywell many years ago (1982), a couple of us 
taught a course in Ada programming, complete with access to our Ada/SIL 
compiler which was of course somewhere between Ada 80 and Ada 83 at the 
time (except for one addition we kept hoping that the ANSI standard 
effort would fix, a decent notation for Boolean array literals).

We used the tapes from the Ichbiah, et. al. course that one of us had 
taken as well as three instructors who were pretty much constantly 
available to the students.  All of the students had been programming OS 
software at Honeywell in various assembler languages for years, and the 
selection process for students was designed to get a representative 
sample of the current Honeywell Small Systems programming staff.

The biggest and most shocking conclusion from the course was that we 
could easily pick out about 30% of the current programming staff who 
would NEVER be able to successfully program in Ada.   The 30% number had 
pretty wide bounds at the time, but we (Honeywell) went further.  We 
wrote a short questionaire that was given to all potential students 
before the course, and later used that questionaire before addtional 
sections of the Ada course, a Pascal course that I taught, and a C course.

Since the students who did well in the Ada course went on to write 
several significant parts of the next OS release in Ada, some from the 
Pascal course to write a section in Pascal, and there were three C 
projects.  (One which ended up using the C preprocessor to write very 
Ada-like code.)  After all this validation, we could use the 
questionaire on applicants for jobs and a larger portion of the existing 
staff.

The final conclusion was that, if you used Ada about 30% of the current 
staff were hopeless.  With C, the number was closer to 5%, in Pascal 
somewhere in between.  Ada showed more than a 100% cost benefit over 
using C, and a 350% benfit over assembler, on initial project costs, 
with Pascal somewhere in the middle.  As for maintenance costs, 
maintaining C code cost around 50% less than maintaining assembler, and 
we had no cost data for fixing bugs in Ada code--even after MOD 400 
Release 3.0 had been in beta test for more than a year, and in general 
release for six months after that.

But there were some serious problems from a management point of view to 
using Ada.  First, the training costs were well justified, but 
retraining everyone would bankrupt the division, whether we used 
internal or external training.  So any switchover would need to be 
evolutionary.  And Ada converts were just that.  They might be willing 
to occasionally use a code insert, or C for some low-level driver, but 
they would quit rather than be put back to working full-time in 
assembler or C once thay had worked on an Ada project for long enough.

Finally, the real bad news from an Ada perspective was using the survey 
on job applicants.  Unlike the numbers for current staff, less than 30% 
tested high enough on Ada compatibility, but 90% were capable of working 
in C.  And one of the biggest descriminators was that debugging question 
of Dewar's.  If you checked "Strongly Agree" to "I enjoy debugging my 
own code," forget Ada.  Even worse was the vote on "I enjoy debugging 
code written by others."  Check "Somewhat Agree" and forget Ada.  Oh, 
and the salery requirements were such that potential Ada programmers 
expected to make about 50% more than potential C programmers.

So the "short-term" decision was to switch from assembler to C for most 
code, and Ada for the more difficult sections of the OS.  I left the 
company before I found out what the long-term decision was, but I 
suspect that Ada was used less and less, not more and more.

Oh, and I can't tell this story without adding one anecdote.  A student 
in the class, Joe, called me up one morning and said he had found a bug 
in the Ada compiler.  Since compiler bugs and teaching the class were 
both high-priority, I asked him to bring his problem up.  He brought a 
listing with over sixty lines of declarations and about half-a-dozen 
statements all in one procedure.  I spend about twenty minuted figuring 
out what he was doing, and scribbled one statement at the bottom of the 
page.

"You can do THAT in Ada?"
"Sure."
"Okay, I'll go try it."
"What about the compiler bug."
"Let me try this instead, I'm not sure my code is right."
"Okay."  I marked two of lines of declarations. "You'll still need these 
lines, but the rest can go."

Ten minutes later, he calls back.  "It still generates the same code."

"Bring up a listing with the assembler output."
"Got one already."

It only took me a minute or so to look at the generated code.  There 
were exactly three one-word instructions for the procedure, and the last 
one was a return statement.  Pretty slick I thought.

"Looks okay to me."
"But you can't do that in three instructions!"
"Did you try running it?"
"Of course not! It can't work."
"Why not."
"It needs four instructions."
"No it doesn't look.  This first instruction loads the value of the 
first parameter into R1, and post-increments the stack pointer.  The 
second instruction indirects through the stack-pointer that now points 
at the second parameter, and indexed by R1.  The third instruction 
pre-decrements the stack pointer and does the return. I'm going to have 
to complement Harlan on this particular peephole optimization."
"But that's cheating!"

I later found out that Joe had "invented" the way to write that 
expression in four instructions, and his real purpose in writing the 
example was to show how inefficient any compiled language was.  Needless 
to say, Joe never turned in a completed assignment, and I think he 
stopped attending the course halfway through.

-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Hyman Rosen]

Robert I. Eachus wrote:
> The final conclusion was that, if you used Ada about 30% of the current 
> staff were hopeless.  With C, the number was closer to 5%, in Pascal 
> somewhere in between.  Ada showed more than a 100% cost benefit over 
> using C, and a 350% benfit over assembler, on initial project costs, 
> with Pascal somewhere in the middle.  As for maintenance costs, 
> maintaining C code cost around 50% less than maintaining assembler, and 
> we had no cost data for fixing bugs in Ada code--even after MOD 400 
> Release 3.0 had been in beta test for more than a year, and in general 
> release for six months after that.

Let me see if I understand this correctly. The acceptance criteria
were looser for programmers of what you and I both agree is a more
error-prone language? Those 30% who were hopeless for Ada were also
hopeless for C. That's why there were maintenance problems with the
C code.

Re: += in ada

[Robert I. Eachus]

Hyman Rosen wrote:

 > Let me see if I understand this correctly. The acceptance criteria
 > were looser for programmers of what you and I both agree is a more
 > error-prone language? Those 30% who were hopeless for Ada were also
 > hopeless for C. That's why there were maintenance problems with the C
 > code.

I'd love to do a wink and a nod, and agree with you.  But I can't.  The
key issue was abstraction.  Some programmers just couldn't get it.  They
could generated decent code in C or assembler, but when it came to Ada,
they, like Joe, couldn't accept the idea of abstraction and information
hiding.  There may have been some way to reach those programmers, but we
didn't find it.  Anyone who gets information hiding tends to love Ada.

It all comes back that debugging question.  With information hiding the
amount of information the programmer needs to understand his code is
limited.  That means that the code--in the context of information
hiding--is much easier to understand.  But you HAVE to do unit test!
Otherwise you are trying to debug at several levels at once, and your
head hurts.

Of course, if you do design and unit testing right, then any bugs you
uncover during unit test are so immediately obvious that there is no
need for a debugger.  I hit one of those bugs last week, an off by one
error in the bounds of a slice.  It was immediately obvious from the
output of the test program which function had failed, and that function
had one assignment statement in it, so I didn't really need the compiler
telling me which line raised Constraint_Error.

The programmers who failed to succeed on the "homework" assignments
almost universally had a problem showing up when they, after skipping 
unit test, tried to debug their programs with the debugger.  Decent 
debugger, but when you are looking at code that is generated from 
multiple levels of abstraction the debugger as such is no help.  You 
have to insert print statements at different abstraction levels to find 
the problem--or go back and write those unit tests.

We called it the "one little bug syndrome" and it was a killer.  And I 
still see it in programmers today.  When their program doesn't work, 
they are sure that there is only "one little bug" remaining and 
suggesting they go back and do it right just infuriates them.

The other failures, although there were officially no grades, were those 
who insisted on working around Constraint_Error or compiler error 
messages rather than try to fix what was wrong.  Again user headspace 
adjustment--they couldn't accept that the compiler was helping them by 
generating all those messages.  It made me very understanding of the 
companies whose Ada policies said "No use of Unchecked_Conversion," and 
change requests for Ada 9X that basically asked for some way to work 
around such "stupid" rules.  Such understanding, of course, did not 
extend to changing the language.  The fact that I knew that many of 
these requests came from employees of companies who had relatively 
liberal policies on exceptions to the project software development guide 
helped me to understand what was going on.  In fact at the Ada 9X 
Requirements meeting in Ft. Walton Beach, I was able to point out that 
several of these requests were worded correctly:  "I am not permitted to 
use Unchecked_Conversion, and..."  Cut it at the and, emphasize the "I" 
and you understood.


-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle."  -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig

Re: += in ada

[Hyman Rosen]

Robert I. Eachus wrote:
> I'd love to do a wink and a nod, and agree with you.  But I can't.  The
> key issue was abstraction.  Some programmers just couldn't get it.

What I am trying to tell you is that those programmers
didn't get C either. The fact that Ada prevented them
from cobbling together a running program and C didn't
is a point in Ada's favor, but that doesn't mean that
the C code they produced was any good.

Re: += in ada

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> The
> key issue was abstraction.  Some programmers just couldn't get it.  They
> could generated decent code in C or assembler, but when it came to Ada,
> they, like Joe, couldn't accept the idea of abstraction and information
> hiding.  There may have been some way to reach those programmers, but we
> didn't find it.  Anyone who gets information hiding tends to love Ada.

Well, I don't like when information is hidden from me. But I certainly like
to hide information from others, especially if I suspect that they will use
that information in wrong way (for example, devaluating or even destroy it).
And yes, as you may guess, I like to hide (or save -;) information from myself
being in some improper state. So, I tolerate this concept.

But this concept sometimes is (yes, really is) a powerful weapon in hands of
fools. There are cases where some design is simply wrong because it hides too
much information (making desired functionality impossible), and every attempt
to correct it leads only to a lecture about importance of information hiding.
That's trivial - they are so proud that they managed to hide some significant
piece of information that they become unable to listen why this information is
needed to other parts of the system.

So, what I certainly dislike is the term "information hiding". It is no much
better than infamous "total informational awareness" -;) . I like "information
structuring", I agree with various boundaries and safety checkpoints, hierachies,
access levels and rights, etc., etc., but not with simple and popular "hiding".




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: += in ada

[Wes Groleau]

Russ wrote:
> Yes, I realize that the issue is complex and many "higher-level"
> problems exist, such as lack of standard libraries, development tools,
> etc. But then you have to ask why those problems developed in the
> first place. I just think that the root cause of Ada's lack of
> popularity, when you get right down to it, is the awkward syntax,

I don't think Ada's alleged "awkward syntax"
is a reason for its unpopularity.  I think that's
a rationalization (i.e., excuse) cooked up by folks
who either don't know or won't admit the real reasons
they don't like it.

As for the lack of libraries, the reason is not
Ada's lack of popularity.  The reasons are:

1. Some of the libraries wanted are not in great
    demand in Ada's original primary problem domain.

2. At one time, even though Ada made it very easy
    to re-use code, contract rules made it difficult.

3. At one time, mandated development methods also
    made it difficult to reuse code.  If it didn't
    _exactly_ meet project requirements, the project
    couldn't use it.

4. The safety-mindedness of Ada folks sometimes
    manifested as not trusting anything that didn't
    jump through the exact hoops of "OUR" process.

5. When (3) and (4) did not apply, sometimes
    people thought they did apply.

probably lots more. ...

-- 
Wes Groleau
    "Would the prodigal have gone home if
     the elder brother was running the farm?"
                       -- James Jordan

Re: += in ada

[Hyman Rosen]

Wes Groleau wrote:
> I don't think Ada's alleged "awkward syntax"
> is a reason for its unpopularity.

All I know is that when I first became aware of Ada many
years ago, my reaction was "Oh no! Pascal! Why did it have
to be Pascal?" (or something to that effect, since I guess
Ada predates the Indiana Jones movies). I don't think I
ever recovered from that initial visceral dislike.

> won't admit the real reasons they don't like it.

So what do you think the "real" reasons are?

> 2. At one time, even though Ada made it very easy
>    to re-use code, contract rules made it difficult.

I don't think it's ever been easy to reuse code.
Ariane 5? (ducking :-)

Re: += in ada

[Preben Randhol]

On 2003-10-21, Hyman Rosen <hyrosen@mail.com> wrote:
> Wes Groleau wrote:
>> I don't think Ada's alleged "awkward syntax"
>> is a reason for its unpopularity.
>
> All I know is that when I first became aware of Ada many
> years ago, my reaction was "Oh no! Pascal! Why did it have
> to be Pascal?" (or something to that effect, since I guess
> Ada predates the Indiana Jones movies). I don't think I
> ever recovered from that initial visceral dislike.

Funny I had the same reaction. However, I recovered fast.

Preben
-- 
"Saving keystrokes is the job of the text editor, not the programming
language."

Re: += in ada

[Marius Amado Alves]

On Tue, 2003-10-21 at 12:07, Preben Randhol wrote:
> Funny I had the same reaction. However, I recovered fast.

Eh eh! I remember when I moved to Ada from C (in 1996) I used to missed
compound assignment and varargs--but I also recovered fast :-)

(However I was very happy with := for assignment right from the start. I
guess I was already generally happy with Pascal syntax.)

Re: += in ada

[Marin David Condic]

With the initial target being embedded programming for military systems, 
there were some very real problems with Ada: It was too big for many of 
the processors of its time (and still is for a lot of small embedded 
processors). There was a general lack of good quality compilers that 
would target those processors (and you *really* needed very high quality 
code generation - remember all those efficiency things surrounding 
Ariane 4 and the hand optimizations?) Ada missed supporting things that 
were seen as "critical" to embedded programming - unsigned integers, 
and/or/xor on words, etc. (And I'll spare Robert the jab about the lack 
of sqrt :-) Ada promised a lot to embedded developers (Chapter 13) but 
was very late in delivering it. Developers had lots of specialized tools 
surrounding their embedded projects and Ada wasn't there with 
replacements. Ada was ahead of compiler technology and the hardware on 
which to run the compilers and nobody was willing to "subset" the 
language to get some portion of it working reliably & efficiently in a 
reasonable time frame, etc., etc., etc.

Add to this some perceptual problems backed up by reality initially, but 
they took a long time to cure. Various language constructs were viewed 
as inherently inefficient - backed up by poor quality compilers. Ada was 
viewed as outrageously expensive and too grandeose for embedded 
programming - backed up by outrageously expensive compilers and lack of 
implementations for embedded targets. That list goes on too.

Toss in a major factor of psychology: Embedded programmers are (or at 
least tended to be back then - maybe attitudes have shifted) "Bit 
Twiddlers". Basically guys who get tied up in the small stuff and often 
miss the "Big Picture". They were used to dealing in raw words and bytes 
with shifts and rotates and such. Ada brought to it a discipline they 
weren't used to and didn't like as they saw it standing in their way. 
The value of strong typing in particular was not seen as "user 
friendly". They tried to write "Adatran" code and found it difficult. So 
they saw Ada as some obstacle that was being forced on them by people 
who knew nothing about how the job was really done. At that point they 
hated Ada and no amount of fixing other problems with the language was 
going to get them to start liking it.

That and various bad management decisions on the part of the powers that 
be who were trying to create/promote Ada, and you had a pretty horrible 
reputation right out of the starting gate. This reputation spread like 
wildfire and has been *enormously* hard to overcome. Some of it is 
reality and some of it is myth, but in the world of "Marketing" - 
"Perception *IS* Reality".

Hence - back on subject - I see no reason to believe that adding trivial 
syntax changes is going to in any way win over the crowd that hated Ada 
for a hell of a lot bigger things than lack of a "+=" operator.

MDC


Hyman Rosen wrote:
> 
> 
> So what do you think the "real" reasons are?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Robert I. Eachus]

Marin David Condic wrote:
 >                               Ada missed supporting things that
> were seen as "critical" to embedded programming - unsigned integers, 
> and/or/xor on words, etc. (And I'll spare Robert the jab about the lack 
> of sqrt :-)

That's all right, you got the order correct.  I thought adding a full 
word unsigned capability was more important, but I lost that 
fight--then.  Well, I didn't quite.  It was perfectly legitimate for 
compilers to treat System.Address as an unsigned word and provide 
operations and literals for it.  But users weren't happy with something 
  that implementation dependent.

> Add to this some perceptual problems backed up by reality initially, but 
> they took a long time to cure. Various language constructs were viewed 
> as inherently inefficient - backed up by poor quality compilers. Ada was 
> viewed as outrageously expensive and too grandeose for embedded 
> programming - backed up by outrageously expensive compilers and lack of 
> implementations for embedded targets...


> Hence - back on subject - I see no reason to believe that adding trivial 
> syntax changes is going to in any way win over the crowd that hated Ada 
> for a hell of a lot bigger things than lack of a "+=" operator.

Totally agree.  Ada has become what it is--a wonderful SYSTEMS 
programming language, a decent language for embedded programming, and 
THE language to use if you care about safety and security.  (Modulo 
whether or not to use the SPARC subset in some real-time--and 
other--contexts.)

The problems that Ada had when it was immature could have been handled 
better.  Those who were there will remember the fiascos of the two 
government backed compiler developments, ALS (Softech) and I can't even 
remember the name of the other one right now.  Neither should be 
considered successful, and it took the "commercial only" compilers such 
as Verdix, Rational, and DEC Ada to rescue Ada from those mistakes.

Incidently, I now know enough that I would instead of pages of detailed 
comments on the proposals I would have made one comment.  "Develop the 
compiler, then award the contract for the APSE.  Otherwise you will be 
doomed to failure."  As it is/was, no viable APSE was ever developed 
back then, although some decent development systems have shown up since.

At MITRE in the 1980s we had a standard of comparison for all the 
proposed APSEs.  We compared them to Verdix Ada, SunOS, emacs, and 
decent support for e-mail.  We never added NFS (network file system) to 
that list becuase no proposed APSE ever measured up--and the actual 
implementations were always worse.

-- 
                                           Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Chad R. Meiners]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F954670.8080004@comcast.net...
> Totally agree.  Ada has become what it is--a wonderful SYSTEMS
> programming language, a decent language for embedded programming, and
> THE language to use if you care about safety and security.  (Modulo
> whether or not to use the SPARC subset in some real-time--and
> other--contexts.)

I think you meant to say SPARK and not SPARC.

Re: += in ada

[Robert I. Eachus]

Chad R. Meiners wrote:

 > I think you meant to say SPARK and not SPARC.

Correct, it was a spelling error.  I guess I have been typing
UltraSPARC a lot recently--mostly in discussions of whether or not the 
architecture is dying.  My fingers seem to have been programmed with a 
SPARC pattern holding the shift key with my right little finger.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle."  -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig

Re: += in ada

[Wes Groleau]

Robert I. Eachus wrote:
> That's all right, you got the order correct.  I thought adding a full 
> word unsigned capability was more important, but I lost that 
> fight--then.  Well, I didn't quite.  It was perfectly legitimate for 
> compilers to treat System.Address as an unsigned word and provide 
> operations and literals for it.  But users weren't happy with something 
>  that implementation dependent.

They could also provide unsigned types in other packages.
Verdix did--unfortunately, they misinterpreted the requirement
that built-in integer types must be symmetrical about zero
to mean that the compiler must refuse to compile any
such type.  So their unsigned package spec was all comments,
and users were prevented from defining any unsigned types.

-- 
Wes Groleau
-----------
Daily Hoax: http://www.snopes2.com/cgi-bin/random/random.asp

Re: += in ada

[Robert I. Eachus]

Wes Groleau wrote:

> They could also provide unsigned types in other packages.
> Verdix did--unfortunately, they misinterpreted the requirement
> that built-in integer types must be symmetrical about zero
> to mean that the compiler must refuse to compile any
> such type.  So their unsigned package spec was all comments,
> and users were prevented from defining any unsigned types.

Please.  I fought very hard for that wording.  Predefined integer types, 
and predefined floating point types.  Oh and also notice, which people 
kept missing, that fixed-point types in Ada 83 had no such restriction, 
and in fact had examples in the manual of how to declare non-negative 
types that filled a byte or word.

By the way, what made you think that users couldn't define unsigned 
types in Verdix?  As I recall, the "special" package provided a 32-bit 
unsigned type that you could derive from or subtype.  All other size 
unsigned types could be defined without problem.  The special problem 
with the 32-bit unsigned type was that Unsigned'Last was greater than 
System.Max_Int.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Wes Groleau]

Robert I. Eachus wrote:
> By the way, what made you think that users couldn't define unsigned 
> types in Verdix?  As I recall, the "special" package provided a 32-bit 
> unsigned type that you could derive from or subtype.  All other size 
> unsigned types could be defined without problem.  The special problem 
> with the 32-bit unsigned type was that Unsigned'Last was greater than 
> System.Max_Int.

Possible my memory is distorted (it's been
at least twelve years) but I seem to remember
not being able to.  Also, the comments in their
package Unsigned did not say anything about unsigned'last,
they said something like (memory again) this package
is all comments because it's illegal to have integer
types that are not symmetrical about zero.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau/Wes

Re: += in ada

[Marin David Condic]

Well, one of the things that was done right with Ada95 was developing 
Gnat and making sure it was out there in Open Source. That gave people 
something that they could use right away and, if the need was there, 
could modify for their own particular targets, etc. Had Ada83 followed 
some similar route, it might have met with more success.

In some ways, I think Ada83 could have succeeded much better if it had 
only been turned into Ada85 - delayed a couple of years to let hardware 
and compiler technology catch up. A descent quality compiler that was 
publically available for some popular and inexpensive platform would 
have gone a *LOT* further back then to help make the language more 
popular. If the DoD had delayed the standard until such a prototype 
compiler could have been released with it, I think that lots of people 
would have tried it and liked it.

One thing to remember is that back then, compilers in general were still 
pretty expensive and hobbyists were just starting to find things like 
Borland Pascal available. Their hardware was pretty small - hard disks 
were quite expensive and lots of systems only had floppies.  I knew 
there were lots of people back then who were excited about Ada and would 
have loved to try it out - perhaps building a lot of the software that 
would have made it more successful - but they were basically frozen out 
of it initially and even when it started to be more practical, the 
quality was poor and sooner or later the discouragement set in and 
people started wandering off to other more accessible technology.

On the up-side, I noticed that there were a hundred-thirty-something 
posts to CLA this morning - a pretty big number. Maybe it reflects some 
increased interest in Ada? Or is it all just a flurry of 
thrusts-jabs-ripostes by the usual suspects? ;-)

MDC


Robert I. Eachus wrote:
> Incidently, I now know enough that I would instead of pages of detailed 
> comments on the proposals I would have made one comment.  "Develop the 
> compiler, then award the contract for the APSE.  Otherwise you will be 
> doomed to failure."  As it is/was, no viable APSE was ever developed 
> back then, although some decent development systems have shown up since.
> 
> At MITRE in the 1980s we had a standard of comparison for all the 
> proposed APSEs.  We compared them to Verdix Ada, SunOS, emacs, and 
> decent support for e-mail.  We never added NFS (network file system) to 
> that list becuase no proposed APSE ever measured up--and the actual 
> implementations were always worse.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Wes Groleau]

Marin David Condic wrote:
> which to run the compilers and nobody was willing to "subset" the 
> language to get some portion of it working reliably & efficiently in a 

Janus was willing.  I had a copy runnable on a CP/M
64 K machine.  Never did anything with it.

> The value of strong typing in particular was not seen as "user 
> friendly". They tried to write "Adatran" code and found it difficult. So 

And people on the other extreme, who thought that just
because the language offered something, you had to use it.

I remember one program that had 26 tasks when given
to me.  When I was done with it, it had five, and
still met all its requirements.

-- 
Wes Groleau
    "Lewis's case for the existence of God is fallacious."
"You mean like circular reasoning?"
    "He believes in God.  Therefore, he's fallacious."

Early Ada Mistakes (was: Re: += in ada)

[Marin David Condic]

Wes Groleau wrote:
 > Marin David Condic wrote:
 >
 >> which to run the compilers and nobody was willing to "subset" the
 >> language to get some portion of it working reliably & efficiently
 >> in a
 >
 > Janus was willing.  I had a copy runnable on a CP/M 64 K machine.
 > Never did anything with it.
 >
I owned one of those too for a PC. Also the Telesoft compiler. Both couldn't
figure out how to get generics implemented, so they ended up with
butt-ugly, non-portable kludges in order to make something vaguely
resembling Text_IO work. Eventually, this got fixed, but, as I observed,
it put people off and made them believe that all the promises were just
hype - that Ada *was* just to big and complicated and inefficient and
would never meet its promises of portability.

BTW, I liked the RR product, so please don't throw stones at me Randy!
However, I don't have anything nice to say about Telesoft - mostly for
bad business practices - so those guys are free to go pile sand. Except
they don't exist anymore. Wonder why? ;-)

As for subsets - that was viewed as heresy at the time. Nobody official
wanted to sanction a subset and most of the potential users didn't seem
to want there to be one. In point of fact, subsets got made anyway, but
there was no "conventional" subset anyone could count on and there were
non-portabilities (as I observed with Text_IO). This ought to be a 
"Lesson Learned" - if the vendors are going to end up doing it anyway, 
then its better to accommodate it in some manner so it gets done in a 
*standard* way.

I thought it would be A Good Thing(tm) had there been some kind of
semi-official subset that could have been validated so that a compiler
might have been "Level 1 Compliant". That may have let compiler writers
come out with something that would have met the needs of us guys with
really small target processors and/or inexpensive home computers. We
would have been able to play the game and do so in a way that was
"Portable". As technology improved, vendors might have more easily
become "Level 2 Compliant" and customers could have upgraded as their
hardware grew to meet the needs.

But that's all 20/20 hindsight. Perhaps if we get to have *another* DoD
mandated programming language.... :-)


 >

 >> The value of strong typing in particular was not seen as "user
 >> friendly". They tried to write "Adatran" code and found it
 >> difficult. So
 >
 >
 > And people on the other extreme, who thought that just because the
 > language offered something, you had to use it.
 >

Yup. You still see that today and not just with Ada. People go off and take
a course and get all hyped up about some particular set of features and
have to run off and make use of each and every one in their first program.

We still occasionally see religious wars here over the use of standard
("Predefined" - Sorry Robert.) Integer and Float types. Some folks
believe it is morally wrong under any circumstances *not* to define your
own types for every conceivable use. Others are more lax about it.

I'm in the "Others" category, but I did learn a lesson about not using
the predefined type Integer in an embedded machine where later, when we
needed to meet requirements to guarantee saturation on overflows, I was
unable to override the "+" (etc) operators. Had I defined my own integer
type, I could have done this. Fortunately, it wasn't too hard to review
the code and determine that we were O.K. without it & get waivers from
the requirement.



 > I remember one program that had 26 tasks when given to me.  When I
 > was done with it, it had five, and still met all its requirements.
 >
I recall one that was built by the Special Olympics Software Development
Team at a company that shall remain nameless. They had been sent off to
Object Oriented Programming School (on the Short Bus) and came back and
turned *everything* into a task. As well you can imagine, this
complicated analysis of program behavior immensely. It could have been
done a hell of a lot simpler, but, well, they *were* the Special
Olympics Software Development Team. :-)

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Early Ada Mistakes (was: Re: += in ada)

[Robert I. Eachus]

Marin David Condic wrote:

> I thought it would be A Good Thing(tm) had there been some kind of
> semi-official subset that could have been validated so that a compiler
> might have been "Level 1 Compliant". That may have let compiler writers
> come out with something that would have met the needs of us guys with
> really small target processors and/or inexpensive home computers. We
> would have been able to play the game and do so in a way that was
> "Portable". As technology improved, vendors might have more easily
> become "Level 2 Compliant" and customers could have upgraded as their
> hardware grew to meet the needs.

There were actually two, pretty well understood by all compiler 
developers.  The first was the Pascal subset, this was basically 
everything in Ada that was also in Pascal.  A lot of compiler developers 
either modified a Pascal compiler to compile this subset, or built a 
tool to convert from the Pascal subset of Ada into Pascal.

The next step up was the Pascal superset.  This was basically everything 
in Ada except chapters 9 (Tasking), 12 (Generics) and most of 13.  This 
was the language that most compiler developers used--and possibly still 
do--to implement the Ada run-time.  Of course, a lot of people would say 
that some compilers, such as the original Telesoft compiler were only 
useable with the Pascal superset.  I am not one of them.  I never found 
the original Telesoft compiler useable.  But then again, maybe I never 
found the right Pascal subset to use with it.

-- 
                                             Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Early Ada Mistakes (was: Re: += in ada)

[Marin David Condic]

Yea, there was the "Pascal-Like Subset" that was a starting point for a 
lot of vendors, but a) it wasn't any kind of approved, validated 
standard, so you couldn't be sure of any kind of portability (every 
vendor had their own rules about what they were going to implement) and 
b) there were things that had to be included that were way off of the 
standard in order to make it work. The most obvious was Text_IO: You 
couldn't do I/O for anything except text (numeric types, enumerations, 
etc.) without generic instantiation and, as you observed, that was the 
"Level 2" part. So compilers had to come up with some sort of hack-job 
to give you I/O for floats, integers, etc., without having generics. 
Double-Plus-Ungood for developing anything you hoped to make portable.

I realize it all got fixed eventually, but it *did* leave a bad taste in 
  the mouths of a lot of users. Ada was supposed to be this wonderful 
language that was going to be portable across all machines and all 
compilers - but the wonderful parts were not there and the portability 
was no better - perhaps worse - than your average Fortran or C compiler. 
Disillusionment followed rapidly.

Even today, I think there might be some food-value in a "standard" 
subset that would be aimed at small embedded machines. (Assuming anyone 
wants to try to venture into that market again.) Spark might make a nice 
start - except that it isn't a "Standard". I don't know enough about 
Spark to know if it limits itself to things that would hack the language 
down to something easily targeted to small embedded machines. It just 
might be valuable to have something that could easily fit a small target.

MDC



Robert I. Eachus wrote:
> 
> There were actually two, pretty well understood by all compiler 
> developers.  The first was the Pascal subset, this was basically 
> everything in Ada that was also in Pascal.  A lot of compiler developers 
> either modified a Pascal compiler to compile this subset, or built a 
> tool to convert from the Pascal subset of Ada into Pascal.
> 
> The next step up was the Pascal superset.  This was basically everything 
> in Ada except chapters 9 (Tasking), 12 (Generics) and most of 13.  This 
> was the language that most compiler developers used--and possibly still 
> do--to implement the Ada run-time.  Of course, a lot of people would say 
> that some compilers, such as the original Telesoft compiler were only 
> useable with the Pascal superset.  I am not one of them.  I never found 
> the original Telesoft compiler useable.  But then again, maybe I never 
> found the right Pascal subset to use with it.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Early Ada Mistakes

[Hyman Rosen]

Marin David Condic wrote:
> I realize it all got fixed eventually, but it *did* leave a bad taste in 
>  the mouths of a lot of users.

Also, let's not forget the Intel 432 processor, which was supposed
to be "Ada on a chip" and which ran like a pig. (Are pigs slow?
The 432 was slow. <http://www3.sk.sympatico.ca/jbayko/cpu7.html>.)

Re: Early Ada Mistakes

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1066919806.19766@master.nyc.kbcfp.com...
>Are pigs slow?

No, they are not!  Hopefully, you'll never be charged at by a pig.

Re: Early Ada Mistakes

[Preben Randhol]

On 2003-10-23, Chad R. Meiners <crmeiners@hotmail.com> wrote:
>
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1066919806.19766@master.nyc.kbcfp.com...
>>Are pigs slow?
>
> No, they are not!  Hopefully, you'll never be charged at by a pig.

From the  RFC 1925 

With sufficient thrust,  pigs fly just fine.  However, this  is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous  sitting under them as  they fly
overhead.                                               

Preben
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Early Ada Mistakes

[Robert I. Eachus]

Preben Randhol wrote:

> With sufficient thrust,  pigs fly just fine.  However, this  is not
> necessarily a good idea. It is hard to be sure where they are going
> to land, and it could be dangerous  sitting under them as  they fly
> overhead.                                               

I remember when the F-4 Phantom II first entered service with the US Air 
Force.  Some wag said:  "Everyone knows that with enough thrust you can 
make a barn door fly.  But that didn't mean that MickeyD (McDonald 
Douglass) had to prove it."

Once an F-4 accidently got launched from a carrier with its wings 
folded.  The pilot flew it "in the pattern" and around to land. I also 
saw an F-4 go from cold engines to 35,000 feet without crossing the end 
of the runway in about 2 minutes.  Only time, other than I guess a Space 
Shuttle launch, when I saw an aircraft gain substantial speed going 
straight up.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Early Ada Mistakes

[Wes Groleau]

Hyman Rosen wrote:

> Marin David Condic wrote:
> 
>> I realize it all got fixed eventually, but it *did* leave a bad taste 
>> in  the mouths of a lot of users.
> 
> 
> Also, let's not forget the Intel 432 processor, which was supposed
> to be "Ada on a chip" and which ran like a pig. (Are pigs slow?
> The 432 was slow. <http://www3.sk.sympatico.ca/jbayko/cpu7.html>.)

" ...promoted as being ideal for the Ada programming language.
   To enforce this, permission and type checks for every memory
   access ... slowed execution ... "

Cute.  Let's support Ada, except let's not support
any efficiency-oriented features like pragma Suppress.

:-)

-- 
Wes Groleau
-----------
Curmudgeon's Complaints on Courtesy:
http://www.onlinenetiquette.com/courtesy1.html
(Not necessarily my opinion, but worth reading)

Re: Early Ada Mistakes

[Robert I. Eachus]

Wes Groleau wrote:

>> Also, let's not forget the Intel 432 processor, which was supposed
>> to be "Ada on a chip" and which ran like a pig. (Are pigs slow?
>> The 432 was slow. <http://www3.sk.sympatico.ca/jbayko/cpu7.html>.)

The problem with the original 432 had nothing to do with Ada, but 
everything to do with the capability model.  When the OS designers found 
out that the only way to extend the top-level capability node was to do 
a hardware reset and in effect reboot with a different top-level node, 
they wanted another hardware turn before the chip started shipping.  The 
executive decision was that the chip was late enough already.

As far as I am concerned, this is what killed the chip family.  It is 
hard to understand if you don't know all the gory details. But the net 
effect was that the top-level node ended up as basically a placeholder, 
with the "real" top-level node one level down in any general-purpose OS. 
  This meant that EVERY memory reference went through an extra level of 
indirection.  Ouch!

Later versions of the chip could cache some capability nodes which 
significantly improved performance. And there was a company in the UK, 
High Integrity Systems that figured out that you could use the chip in 
embedded applications where you migrated all the important capabilities 
into the root node at compile time.  But it was too late to save the 
architecture.

-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Early Ada Mistakes

[Marin David Condic]

Yeah, you'd not want to carve in silicon all the features that should be 
maleable in software. But that was a mistake in judgement that might 
have had some impact on creating the impression that Ada was inherently 
slow. What *does* make sense is to make sure you have primitives that 
make the job easier. Things like supporting context switching 
efficiently so that tasks are faster, etc. To that end, Ada has 
contributed something to the world of microprocessors.

MDC

Wes Groleau wrote:

> 
> Cute.  Let's support Ada, except let's not support
> any efficiency-oriented features like pragma Suppress.
> 
> :-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Early Ada Mistakes

[Wes Groleau]

Marin David Condic wrote:
> I realize it all got fixed eventually, but it *did* leave a bad taste in 
>  the mouths of a lot of users. Ada was supposed to be this wonderful 
> language that was going to be portable across all machines and all 
> compilers - but the wonderful parts were not there and the portability 

To me it was "a language so big the compiler
won't fit on today's home machines" and I did
nothing with it until a few years later my employer
offered an intro course in it.  We were not using
it on any project at the time (AFAIK) although we
were bidding on AN/BSY-2.  I took the course and liked
what I saw.

Now when someone complains it's too big, I think
"Big, but organized; as opposed to just big, like ____"

:-)

-- 
Wes Groleau
-----------
Daily Hoax: http://www.snopes2.com/cgi-bin/random/random.asp

Re: Early Ada Mistakes

[Wes Groleau]

Marin David Condic wrote:
> As for subsets - that was viewed as heresy at the time. Nobody official
> wanted to sanction a subset and most of the potential users didn't seem

That's why they called it "Janus" instead of "Ada"

-- 
Wes Groleau

  Guidelines for judging others:

  1. Don't attribute to malice that which
     can be adequately explained by stupidity.

  2. Don't attribute to stupidity that which
     can be adequately explained by ignorance.

  3. Don't attribute to ignorance that which
     can be adequately explained by misunderstanding.

Re: Early Ada Mistakes

[Marin David Condic]

Sure. But if there had been some recognition of the need to have a 
subset, perhaps there could have been a lower-level standard that would 
have allowed Janus to call itself "Ada" and perhaps met the needs of 
some larger market segment.

I thought the biggest flaw in there was having to kludge up something to 
get Text_IO to work. Perhaps today, with the 'Image and 'Value 
attributes, there could have been something that would have worked with 
simple subprogram calls rather than generics. That would have made it 
easier to develop a standard, portable, upward-compatible subset of Ada 
that included the things one would normally expect of Pascal or C or 
Fortran. It could have been a competitor for those languages at its 
outset and held forth the promise of more to come as technology improved.

Water under the bridge though - and no way to prove or disprove the 
theory. Still, the lesson ought to be "If the vendors are going to end 
up doing it anyway, better to get them doing it all in the same way 
through some sort of recognized standard."

MDC


Wes Groleau wrote:
> Marin David Condic wrote:
> 
>> As for subsets - that was viewed as heresy at the time. Nobody official
>> wanted to sanction a subset and most of the potential users didn't seem
> 
> 
> That's why they called it "Janus" instead of "Ada"
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3F952A59.5090001@noplace.com>...

> That and various bad management decisions on the part of the powers that 
> be who were trying to create/promote Ada, and you had a pretty horrible

Naw ... I don't believe it!

> reputation right out of the starting gate. This reputation spread like 
> wildfire and has been *enormously* hard to overcome. Some of it is 
> reality and some of it is myth, but in the world of "Marketing" - 
> "Perception *IS* Reality".
> 
> Hence - back on subject - I see no reason to believe that adding trivial 
> syntax changes is going to in any way win over the crowd that hated Ada 
> for a hell of a lot bigger things than lack of a "+=" operator.

That's all very interesting, but the fact is that Ada was mandated by
the DoD for much more than just embedded systems. My understanding is
that it was mandated for pretty much everything, right down to
personnel management and payroll systems.

So here you had a $300,000,000,000/year behemoth driving the adoption
of a particular programming language like nothing we've ever seen
before or since -- and never will, for that matter. That in itself
blows all the excuses out of the water as far as I am concerned. Think
about it. If the DoD spent only 1% of its budget on software, that was
approximately $3,000,000,000/year going directly to Ada development.
And I'll bet they spend *much* more than 1%.

You know I agree that Ada is a fundamentally sound language. If it's
half as good as we think it is, and if it is so much more productive
than C and C++, why aren't the masses who were forced to use it now
singing its praises? Something else is going on here, and I think most
of you here are blind to that reality. You can ridicule me all you
want about ":=" and "+=", but I think the last laugh will be on you
when the reality of Ada's demise finally hits you.

Re: += in ada

[Preben Randhol]

On 2003-10-22, Russ <18k11tm001@sneakemail.com> wrote:
> You know I agree that Ada is a fundamentally sound language. If it's
> half as good as we think it is, and if it is so much more productive
> than C and C++, why aren't the masses who were forced to use it now
> singing its praises? 

Probably because of: "Forced to use it" (don't you remember hating the
books you were forced to read in school?) and perhaps Ada 83.

> of you here are blind to that reality. You can ridicule me all you
> want about ":=" and "+=", but I think the last laugh will be on you
> when the reality of Ada's demise finally hits you.

Oh, yes because the lack of += is the *real* reason people are not using
Ada as much as we'd like.

Preben

Re: += in ada

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7667 bytes --]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0310212256.6bdd348d@posting.google.com...
>
> Naw ... I don't believe it!

*** And I don't believe you ;-).  No pun intended.   But from my research,
Marin is right. well not 100% right but the part he explains is very real.
Other than that, Ada compiler vendors lacked a good sales department at the
time.  Like OS/2 (which was far better than Windows at the time, hands down,
for all the right reasons, didn't have Bill Gates (so to speak). If they
did, we'd probably all be on OS/2 today.  The same goes for Ada.  If Ada
started out as Ada 95 back when it first came out and not Ada 80 or 83, I'm
sure things would be very different.

*** Before Windows 2000 and XP, why do you supposed Windows was so popular?
Better than OS/2 ?  I sincerely don't think so.  a good part of it was
marketing.  The other part was the problems computer vendors had ridding
themselves of Windows, Talk to Compaq, and other computer manufacturers,
Compaq, a couple years ago, attempted to provide Linux as their base OS
instead of windows.  that was a bad mistake, not in the eyes of computer
users, but in the eyes of Microsoft it was.  Anyone here remember hearing
about that?  And now AMD or Pheonix (don't remember which) are making BIOS
that are Windows only?  Wonder what number on the check was needed to make
that happen? ;-).

*** I've been in the computer industry for 12 years professionally so far,
and about 27 years on a personal basis (since the micro-computer hit the
market back in 1976)...I've had a chance to follow through the evolution of
the PC and software industry And this situation I've seen happen for more
than Just Ada.

>
> > reputation right out of the starting gate. This reputation spread like
> > wildfire and has been *enormously* hard to overcome. Some of it is
> > reality and some of it is myth, but in the world of "Marketing" -
> > "Perception *IS* Reality".
> >
*** I agree with this.  See my Windows and OS/2 statement above.

> That's all very interesting, but the fact is that Ada was mandated by
> the DoD for much more than just embedded systems. My understanding is
> that it was mandated for pretty much everything, right down to
> personnel management and payroll systems.
>
*** They could have done that with Pascal at the time without a problem.
From my readings They were looking for Safety critical, realtime,
multi-tasking and embedded capabilities payrolls and personelle maangement
came after the language was created (I guess they figure hey we got the
language, let's use it ;-).  But I dont beleieve it was created to
accomodate accounting functionalities as any other languages could have
taken care of that at the time :-).

> So here you had a $300,000,000,000/year behemoth driving the adoption
> of a particular programming language like nothing we've ever seen
> before or since -- and never will, for that matter. That in itself
> blows all the excuses out of the water as far as I am concerned. Think
> about it. If the DoD spent only 1% of its budget on software, that was
> approximately $3,000,000,000/year going directly to Ada development.
> And I'll bet they spend *much* more than 1%.
>
*** Again with this paragraph you just prove Marin's point.  Think about it
too :-).  But what I'm reading here is "You got the best language there ever
was, is, and ever will be"  but like many other projects, they didn't have
the marketing power they needed and as Marin says, "Perception really is
reality"  But that's not the only reason why.  There was a "copycat" effect
from Project managers in the corporate world that decided to go with VB, or
C or C++ for only one reasons, their allies or competition were using these
languages.  They didn't bother doign any serious research on what language
would be best suited for the job, if any of them would do the research, We'd
be readign about C in our history books.  Because 60% (at least, I'm being
pecimist here) of the people and companies using C and C++ aren't doing so
because C++ is good (I'm not saying it's not good, I'm saying it's not the
reason why it was selected).  They used C++ because:

Corporately:
a. It was imposed upon them by their Project managers, I've seen this happen
many times, and the PM again didn't do research, he just used the copy cat
effect and used whatever the others were using.

b. Since C and C++ was used, then newcomers to programming, who wanted a
job, looked at the papers and noticed that there was a lot of C++ in demand,
well what else would they learn if they wanted to work?


*** To me, these are not the right reasons to select a language, it was the
"easy way out" for the corporate world.  Since people learned C and C+++ to
assure themselves a job (again for wrong reasons the corporations were using
C and C++ so if you wanted to work there, you had to know C and C++.  That
doesn't make it Good or Better.  It makes it the only choice.  Call it a
form of corporate dictatorship if you will.

*** For personal programmers working on their own games for example:  google
for game development, and C++ pops up.  for the same reasons because others
used it for Games programming, newcomers that want to make a game go by what
they see, not by what they should see.  so fi they search for game engines,
C++ is bound to popup.  they'll try to do their game in C++ because they
want to use that engine.  Again understand that I'm not sayign that C++ is
not a good choice for games, I'm saying that programmers aren't choosing C++
because it's good, they are choosing it because it's what others have
chosen.  They dont ask the other programmers why did you choose it or try to
find out why it's popular.  Which again proves Marin's point that Perception
Is Reality.


> You know I agree that Ada is a fundamentally sound language. If it's
> half as good as we think it is, and if it is so much more productive
> than C and C++, why aren't the masses who were forced to use it now
> singing its praises? Something else is going on here, and I think most
> of you here are blind to that reality. You can ridicule me all you
> want about ":=" and "+=", but I think the last laugh will be on you
> when the reality of Ada's demise finally hits you.

*** Ada's Demise? Blasphemis.  I see C++ and other language users switching
to Ada, but I don't see Ada developers switching to something else!!! ;-).
If you're still posting on this newsgroup in 5 to 10 years (max), you'll be
giving us your most sincere apologies :-).  Again no pun intended Russ, but
that's just my prediction.

*** More and more corporate people I've talked to, worked in or heard about
(from friends) are getting fed up with never being able to meet deadlines
because there's either problems with the code and the compilers they use,
or, because of upgradability problems  What are they using? C++
:-)...Microsoft did a research on this...results?  C#  Now c# is a mistake
in it's definition.  It's a Javatized C++ dialect.  It is far from getting
the success they thought it would but at least they seem to think that C++
days are counted since they are trying to create an alternative language.
What forced them to do so?

*** Portability was another issue (a programmer I worked with created a
whole system in Linux using what was described as standard C++. When he went
to compile that in Visual C++ he had to change 50% at least of his code to
get it to compile).

*** All Ada needs is a good marketing effort, and from what I hear, it's
about to get just that, we'll talk after and see what happens :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: += in ada

[Robert I. Eachus]

Stephane Richard wrote:

>           The other part was the problems computer vendors had ridding
> themselves of Windows, Talk to Compaq, and other computer manufacturers,
> Compaq, a couple years ago, attempted to provide Linux as their base OS
> instead of windows.  that was a bad mistake, not in the eyes of computer
> users, but in the eyes of Microsoft it was.  Anyone here remember hearing
> about that?  And now AMD or Pheonix (don't remember which) are making BIOS
> that are Windows only?  Wonder what number on the check was needed to make
> that happen? ;-).

Almost certainly Phoenix.  AMD funded the SuSE work on porting Linux to 
the AMD64 architecture.  And AMD is definitely in Microsoft's good 
graces because 64-bit Windows outperforms Linux on the (AMD) Opteron, 
but almost all Itanium-2 sales seem to be HP-UX or Linux.

-- 
                                          Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Wes Groleau]

Russ wrote:
> You know I agree that Ada is a fundamentally sound language. If it's
> half as good as we think it is, and if it is so much more productive
> than C and C++, why aren't the masses who were forced to use it now
> singing its praises? Something else is going on here, and I think most

We are.  Those of us capable of dealing with abstractions
instead of implementations and "doing it right" instead
of slinging code as fast as possible.  Those of us having
that odd character flaw that we don't mind not being able
to spend lots of time debugging.  Those of us who aren't
desperate to get C++ and Java on our r�sum�s.

-- 
Wes Groleau
Can we afford to be relevant?
http://www.cetesol.org/stevick.html

Re: += in ada

[Hyman Rosen]

Dennis Lee Bieber wrote:
> Would it help you to learn that all four of the teams in the proposal 
> phase concluded Pascal was the language closest to meeting the DoD 
> requirements, and therefore the starting point for designing a new 
> language?

No, not at all.

> They tried reuse at too high a level

That's why reuse is hard - the effort to determine suitability for
reuse may be equivalent to the effort to rewrite.

Re: += in ada

[Alexandre E. Kopilovitch]

Russ wrote:

> As I said before, I am not a professional programmer or computer
> scientist. I am aerospace engineer working on future concepts for
> safety critical air traffic management systems 20 years in the future.
> I would like to think that Ada will be an option when the time comes
> to implement my concepts, but I am losing hope.

I really can't guess why you, being an experienced professional in one field,
are disputing a strong and coherent opinion of other professionals on their
territory?

Note that, after all, there are quite influental persons in Ada world -
compiler vendors, for example - whose current business (and not some hopes
for the indefinite future) heavily depends (or even is based) on Ada, and
therefore they are quite concerned with survival of Ada. Do you think than
they are all blind? That they, with all their experience (note also, that
they are usually linked to C one or another way, so they surely are aware of
augmented assignments) and *current* customer base just don't pay attention
to a customer's need? 

> Because my formal training is not in programming or computer science,
> I have restricted my comments on Ada to relatively low-level aspects
> of the language. I don't consider myself qualified to comment on more
> complicated issues. However, judging by my experience here, I am
> losing faith in the Ada community.

I just wonder from where your past faith in Ada community was originated.
What was changed dramatically since that?

> If you can't get the little things right,

Once more, how can you - not professional programmer, as you said yourself - 
be so sure that you know what is right in those little programming things?
So sure that you are trying to press your opinion against a bunch of professional
programmers with very solid experience?

> how in the world can you can the complicated things right?

Simple enough - just look at those complicated things that were already done
recently. Some of them are quite impressive, even in conference articles.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: += in ada

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2816 bytes --]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.127.1066703735.25614.comp.lang.ada@ada-france.org...
>
> I really can't guess why you, being an experienced professional in one
field,
> are disputing a strong and coherent opinion of other professionals on
their
> territory?
>
> Note that, after all, there are quite influental persons in Ada world -
> compiler vendors, for example - whose current business (and not some hopes
> for the indefinite future) heavily depends (or even is based) on Ada, and
> therefore they are quite concerned with survival of Ada. Do you think than
> they are all blind? That they, with all their experience (note also, that
> they are usually linked to C one or another way, so they surely are aware
of
> augmented assignments) and *current* customer base just don't pay
attention
> to a customer's need?
>
*** What makes or breaks a language today isn't what the language can do,
it's how you sell it.  oh and take things about 2 years back (maybe less)
where VB became so popular, does VB have += ?  is vb more performant than
Ada (don't make me laugh).  But this is jus tto illustrate my point.  some
languages (including C and C++ had good sales departments then everything
ramified from that. So when I hear that languages like C++ are popular
because they are performant, well like all languages, and C++ is no
exception to it, anyone can write bad, slow code in any language. I've seen
code that produced the same result actually run faster in VB than it's C++
equivalent (which is sad to say, but true).  So no, not all the right
reasons determine a langauge's popularity.  All it took was a quick boost in
popularity and the rest was side effects (companies using C++ because that's
what either their allies or their competition was using, they didn't look
further than that to decide which language to use.

> I just wonder from where your past faith in Ada community was originated.
> What was changed dramatically since that?
>
*** A good question :-).  Since for me, it worked the opposite way in the
past year and a half.  I don't come from an Ada background, but the language
features (pretty much all of them too:-), and the community is what
converted me (can I say converted on a national Board?  this sounds a bit
religious, no Ada representative came knocking at my door at 6 AM on sunday
morning here ;-)...


> > If you can't get the little things right,
>
> Once more, how can you - not professional programmer, as you said
yourself -
> be so sure that you know what is right in those little programming things?
> So sure that you are trying to press your opinion against a bunch of
professional
> programmers with very solid experience?
>
*** Indeed how?

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: += in ada

[Wes Groleau]

Robert I. Eachus wrote:
> you are fighting. It is a readability issue.  How many times do I have 
> to misread :+ as := to wipe out all the advantage from adding :+ to Ada? 

Worse yet, have your finger miss or slip off
the shift key when trying to type ":+"

-- 
Wes Groleau
   "Grant me the serenity to accept those I cannot change;
    the courage to change the one I can;
    and the wisdom to know it's me."
                                -- unknown

Re: + in ada

[Russ]

Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bmjk73$niepa$1@ID-175126.news.uni-berlin.de>...
> Hyman Rosen wrote:

> >Even in COBOL you could say "ADD A TO B."
> 
> You can already do it in Ada, too:
> 
> |Add (A, To => B);

When I see stuff like this, it offends my sense of elegance in
numerical programming. I don't claim to be a top expert in this area,
but a few years ago I did write software for an experimental real-time
DGPS/INS precision landing system (in C++). I took pride in my code,
and I would have been disgusted to see something like "Add (A, To =>
B)" anywhere in my code.

I heard an interesting little story once about the Queen of England
asking Louis Armstrong (I think it was) about the appeal of jazz. I
don't remember his exact reply, but it was something to the effect of,
"If you have to ask, you don't get it." And I say, if you think "Add
(A, To => B)" is as clean and clear as "B :+ A", you don't get it. But
that's just my opinion, of course.

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Russ wrote:

>Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote in message news:<bmjk73$niepa$1@ID-175126.news.uni-berlin.de>...
>> Hyman Rosen wrote:
>
>> >Even in COBOL you could say "ADD A TO B."
>> 
>> You can already do it in Ada, too:
>> 
>> |Add (A, To => B);
>
>When I see stuff like this, it offends my sense of elegance in
>numerical programming.

Well, I answered to a COBOL snippet, not to FORTRAN. :)

>"If you have to ask, you don't get it." And I say, if you think "Add
>(A, To => B)" is as clean and clear as "B :+ A", you don't get it.

Of course. :) I'll never understand why someone should write "B :+ A"
instead of a more mathematical way "B := <idem> + A"[0] or even the
plain "B := B + A".

There's no need turning procedures into functions.


Vinzent.

[0] Yes, I would support such an approach. Not that I really needed
it, but in case of complex expressions for the left hand side it might
be useful indeed.

Re: + in ada

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
: When I see stuff like this, it offends my sense of elegance in
: numerical programming. I don't claim to be a top expert in this area,
: but a few years ago I did write software for an experimental real-time
: DGPS/INS precision landing system (in C++).

So, based on this experience, could you give an indication of
the frequency and frequent usefulness of :/ in numerical
computing?
In how many cases out of 100 is :+, or :- used do advance an iterator?
(If so, why don't we just want to have a useful abstraction for that?)

How about frequency and usefulness of the statements A :and B;,
or A :xor B;, when compared to inlined procedures naming the purpose
of the operation?


Georg

Re: += in ada

[Russ]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<bmjfri$731$1@a1-hrz.uni-duisburg.de>...
> Russ <18k11tm001@sneakemail.com> wrote:
> :> > > On 2003-10-07, Russ <18k11tm001@sneakemail.com> wrote:

> :> > > > Repeat after me: Augmented assignment is available and WIDELY USED in
> :> > > > C, C++, Java, Perl, and Python, perhaps the 5 most popular
> :> > > > general-purpose programming languages ever designed.

> Interesting. So programming languages are obviously chosen because
> there is some form of augmented assinment in the language?
> Why do people choose Visual Basic, or Fortran, or Delphi?

No, that's not what I said. What I am suggesting is that some
programmers might be turned off by a programming language that does
not provide augmented assignment operators.

Suppose you were out shopping for a new car. Would you say to
yourself, "I will only consider cars that are equipped with visors."
Of course not, because you expect all cars to have visors by now.

Now suppose you are test driving a car. You pull out of the driveway,
and the sun hits your eyes and blinds you. You reach for the visor,
but none is available. "WTF?", you say, "No friggin' visor?

So the salesman in the passenger seat says, "You don't *need* a visor.
All you have to do is put your hand in front of your eyes. What the
heck is so hard about that? Oh, and if that is too much for you, you
lazy bum, you can use some duct tape and cardboard to make your own
visor. There's nothing to it"

Would you buy the car? I doubt it.

So it is with augmented assignment operators (or whatever you want to
call them). They are a basic convenience that a modern general-purpose
programming language is simply expected to have.

As for Visual Basic, yes it is popular, but I hope you aren't
suggesting that it is a good model for programming languages. I
suspect that most VB programmers are clueless about the alternatives
(and also think Linux is too complicated to use).

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Russ wrote:

>No, that's not what I said. What I am suggesting is that some
>programmers might be turned off by a programming language that does
>not provide augmented assignment operators.

Well, I was turned on by Ada because it did *not* have them. But of
course, I'm different than most programmers. I'm using Ada. :-P


Vinzent.

Re: += in ada

[Wes Groleau]

Russ wrote:
> Suppose you were out shopping for a new car. Would you say to
> yourself, "I will only consider cars that are equipped with visors."
> Of course not, because you expect all cars to have visors by now.

Poor analogy.  "+=" isn't like visors.  It's more like
power windows.  Some people think they are indispensable;
others think, "Nice, but I'd never pay extra for them."

Some even say, "Not on your life!  That's a tenth of a mile
less per gallon!"

-- 
Wes Groleau
   "Grant me the serenity to accept those I cannot change;
    the courage to change the one I can;
    and the wisdom to know it's me."
                                -- unknown

Re: += in ada

[Marin David Condic]

More like "What if I drive my car into a canal and the power windows 
won't work. I drown? Give me an old-fashioned crank so I have some 
safety here!"

MDC


Wes Groleau wrote:
> 
> Some even say, "Not on your life!  That's a tenth of a mile
> less per gallon!"
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Preben Randhol]

On 2003-10-17, Marin David Condic <nobody@noplace.com> wrote:
> More like "What if I drive my car into a canal and the power windows 
> won't work. I drown? Give me an old-fashioned crank so I have some 
> safety here!"

But 98% of drivers use cars with power windows! ;-)

Preben
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting is a bad thing!

Re: += in ada

[sk]

Preben Randhol <randhol+valid_for_reply_from_news@pvv.org>:
 > But 98% of drivers use cars with power windows! ;-)

But only 66% of the cars I use have power windows.

Does this exclude me from the 98% sample set ?
Does this exclude me from the  2% sample set ?

Or does this mean that 2/3 of the time I belong to the 98%
set and 1/3 of the time I belong to the 2% set ?

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[Preben Randhol]

On 2003-10-17, sk <noname@myob.com> wrote:
> Preben Randhol <randhol+valid_for_reply_from_news@pvv.org>:
> > But 98% of drivers use cars with power windows! ;-)
>
> But only 66% of the cars I use have power windows.
>
> Does this exclude me from the 98% sample set ?
> Does this exclude me from the  2% sample set ?
>
> Or does this mean that 2/3 of the time I belong to the 98%
> set and 1/3 of the time I belong to the 2% set ?

No it means you belong to the 1.8% who drive both types and not to the
0.2% which only drive cars with powerless windows ;-)

It also means that 98% of drivers wouldn't have driven 33% of your cars
;-)

Preben
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting is a bad thing!

Re: += in ada

[Dmytry Lavrov]

18k11tm001@sneakemail.com (Russ) wrote in message > 
> 
> OK, I can see how you could have misunderstand my point here, so let
> me clarify.
> 
> I am *not* claiming that augmented assignment operators (":+", ":-",
> ":*", ":/") are good *because* 98% of programmers use them. What I am
> claiming is that 98% of programmers use them *because* they are a good
> idea.
I simply can't understand difference.
"Because of A,B is good" vs "B is good because of A"
In both cases you're referring to A,to "prove" that B is good,right?
And A="choise of 98%" ,so you're mean "be with 98%".

Main problem that in some languages thare are no difference between
"because A, B is good", or "B is good ,because A".I don't know if
there are difference in English,and i don't know that ANY language
really have difference.In Russian,it's only order of words.
Of course,advertisement texts almost always uses "because of A,B is
good".


> And I have given three good reasons why augmented assignment
> operators can enhance both readability and efficiency. I won't go over
> them again here because if you don't get it by now you never will.
> 
> > I'm is a beginner in ada,moving from Free Pascal(and also i can code
> > in java and c) where(if FP too) += are supported, and I DON'T WANT +=
> > .
> > Even beginners don't want it!
> 
> This is precisely the attitude that bothers me. I spend all kinds of
> time carefully explaining why the five most popular programming
> languages all have augmented assignment, and all I get back is, "I
> don't like it!", " I don't want it!", and "Even beginners don't want
> it!" No rational reason given.
Hmmm.

We are talking about fact that infix procedures are more readable,
comparing a:+b with inc(a,b) ,right? What it have to do with
efficiency?
Yes,math uses infix functions(you're calling it operators) because 'em
are SOMETIMES more readable.But math don't like notation a f b

I gave reasons,at start of thread:
z :juliafractal c;
does not seems to be more readable.
Problems with :* if  a*b<>b*a
Problems with :\ when we want a:=c/a
Where a X b <> b X a ,we will have problems with :X

Main reason why i don't want :+  :
less shugar,better language.Remember pascal's "writeln" : you're want
to add "mywriteln" with same syntax,but simply can't.

And a b c d e f g
(mean d(b(a,c),f(e,j)))
is not a readable thing.

If language already have way to add user-defined infix procedures,":+"
is not so bad.

> 
> The only rational reply I have received so far is that augmented
> assignment operators are too much effort to implement. Well, they
> obviously weren't too much effort for C, C++, Java, Perl, and Python.
> It's really too bad that Ada is so strapped for support. That obvously
> doesn't bode well for the future of Ada.

Re: += in ada

[Russ]

dmytrylavrov@fsmail.net (Dmytry Lavrov) wrote in message news:<49cbf610.0310150616.3503a1c4@posting.google.com>...
> 18k11tm001@sneakemail.com (Russ) wrote in message > 
> > 
> > OK, I can see how you could have misunderstand my point here, so let
> > me clarify.
> > 
> > I am *not* claiming that augmented assignment operators (":+", ":-",
> > ":*", ":/") are good *because* 98% of programmers use them. What I am
> > claiming is that 98% of programmers use them *because* they are a good
> > idea.
> I simply can't understand difference.
> "Because of A,B is good" vs "B is good because of A"
> In both cases you're referring to A,to "prove" that B is good,right?
> And A="choise of 98%" ,so you're mean "be with 98%".

The statements,"Because of A,B is good" and "B is good because of A"
are indeed equivalent. But that's not the distinction I was making. My
distinction is between "A is good because almost everybody uses it"
and "Almost everybody uses A because it is good."

This is a very fundamental distinction, and its is also the source of
much subtle distortion. Let me give an example.

I happen to believe that the war in Iraq was wise to pursue. A tyrant
was toppled, 25 million people were freed from a hideous tyranny, and
I believe that worldwide terrorism was dealt a massive (though
obviously non-fatal) blow. You can be sure that Osama bin Laden was is
not happy about the war and its outcome.

You may not agree with me, but I did give two or three reasons to back
my position. I understand that there are arguments for the opposite
position, but I am offended when some anti-war protestor compares
George W. Bush to Adolf Hitler.

I think those protestors are unpatriotic idiots. But here's the
critical point. I don't think they are idiots *because* they are
unpatriotic; I think they are unpatriotic *because* they are idiots.
The former would constitute simple-minded patriotism -- "My country,
right or wrong." The latter constitutes intelligent patriotism -- "My
country *is* right this time."

Whenever someone criticizes the idiot protestors, the liberal media is
usually there to subtly imply that it is due to the simple-minded sort
of patriotism. But usually it isn't.

I hope I made my point (considering how much time I just wasted on
this post!).

> We are talking about fact that infix procedures are more readable,
> comparing a:+b with inc(a,b) ,right? What it have to do with
> efficiency?

I've explained this ad nauseum already, so I'll just sum it up. For
user-defined types (vectors and matrices, for example), the augmented
assignment operators allow the programmer to define in-place
operations that do not need temporaries and extra copying as the
standard math operators do.

Consider the common operation of scaling a vector, for example. I
could write

   vec := vec * factor
or
   vec :* factor

The first form requires the construction of a temporary, the actual
scaling operation, then the copying back of the temporary to the
original vector. The latter, on the other hand, can be written to
avoid the construction of the temp and the copying back.

And yes, it is possible for a "smart" compiler to automatically
implement the former with the efficiency of the latter, but current
compilers don't, and more complicated examples would be *extremely*
difficult for the compiler to optimize.

Re: += in ada

[Lutz Donnerhacke]

* Russ wrote:
> Consider the common operation of scaling a vector, for example. I
> could write
>
>    vec := vec * factor
> or
>    vec :* factor
>
> The first form requires the construction of a temporary, the actual
> scaling operation, then the copying back of the temporary to the
> original vector. The latter, on the other hand, can be written to
> avoid the construction of the temp and the copying back.

Wrong! In the case of an exception, the original values need to be retained
in order to keep in touch with the current Ada feelings. So any 'idem'
notation or 'augmented assignment' requires a temporary copy as strong than
the original form.

Re: += in ada

[Russ]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message news:<slrnbot4mg.nr.lutz@taranis.iks-jena.de>...
> * Russ wrote:
> > Consider the common operation of scaling a vector, for example. I
> > could write
> >
> >    vec := vec * factor
> > or
> >    vec :* factor
> >
> > The first form requires the construction of a temporary, the actual
> > scaling operation, then the copying back of the temporary to the
> > original vector. The latter, on the other hand, can be written to
> > avoid the construction of the temp and the copying back.
> 
> Wrong! In the case of an exception, the original values need to be retained
> in order to keep in touch with the current Ada feelings. So any 'idem'
> notation or 'augmented assignment' requires a temporary copy as strong than
> the original form.

We've been over this ad nauseum already. One of the Ada experts
clarified it for us, and if I recall correctly, I think you are
mistaken. Actually, I think you are "Wrong!".

Also, the ":+" form is *not* an assignment statement. It is equivalent
to a procedure call. If the procedure call needs a temp, then Ada is
inherently less efficient than C++ in that regard.

Re: += in ada

[Lutz Donnerhacke]

* Russ wrote:
>> Wrong! In the case of an exception, the original values need to be
>> retained in order to keep in touch with the current Ada feelings. So
>> any 'idem' notation or 'augmented assignment' requires a temporary copy
>> as strong than the original form.
>
> We've been over this ad nauseum already. One of the Ada experts
> clarified it for us, and if I recall correctly, I think you are
> mistaken. Actually, I think you are "Wrong!".

Please read my wording instead of interpreting them. "In order to keep in
touch with the current Ada feelings."

OTOH the break of such feelings are generated by complex data types, not by
ordinary once. This becomes much more important on Volatile and Atomic
variables.

> Also, the ":+" form is *not* an assignment statement. It is equivalent
> to a procedure call. If the procedure call needs a temp, then Ada is
> inherently less efficient than C++ in that regard.

The required temporary exists for a purpose: Exception handling.
All language semantices have such purposes. Please stop argumenting, that
all language designers unlike Bjarne are braindead.

OTOH: What does a:*a when a is of type matric (vector was your example)?
      Here a temporary is required by the mathematical procedure itself.
      So what about your claim?

Re: += in ada

[Dmytry Lavrov]

1:ADA already have "augmented assignment" because ada have "in
out"!!!!!!!!!!



18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0310152140.32c77feb@posting.google.com>...
> dmytrylavrov@fsmail.net (Dmytry Lavrov) wrote in message news:<49cbf610.0310150616.3503a1c4@posting.google.com>...
> > 18k11tm001@sneakemail.com (Russ) wrote in message > 
> > > 
> > > OK, I can see how you could have misunderstand my point here, so let
> > > me clarify.
> > > 
> > > I am *not* claiming that augmented assignment operators (":+", ":-",
> > > ":*", ":/") are good *because* 98% of programmers use them. What I am
> > > claiming is that 98% of programmers use them *because* they are a good
> > > idea.
> > I simply can't understand difference.
> > "Because of A,B is good" vs "B is good because of A"
> > In both cases you're referring to A,to "prove" that B is good,right?
> > And A="choise of 98%" ,so you're mean "be with 98%".
> 
> The statements,"Because of A,B is good" and "B is good because of A"
> are indeed equivalent. But that's not the distinction I was making. My
> distinction is between "A is good because almost everybody uses it"
> and "Almost everybody uses A because it is good."
> 
> This is a very fundamental distinction, and its is also the source of
> much subtle distortion. Let me give an example.
> 
> I happen to believe that the war in Iraq was wise to pursue. A tyrant
> was toppled, 25 million people were freed from a hideous tyranny, and
> I believe that worldwide terrorism was dealt a massive (though
> obviously non-fatal) blow. You can be sure that Osama bin Laden was is
> not happy about the war and its outcome.
> 
> You may not agree with me, but I did give two or three reasons to back
> my position. I understand that there are arguments for the opposite
> position, but I am offended when some anti-war protestor compares
> George W. Bush to Adolf Hitler.
> 
> I think those protestors are unpatriotic idiots. But here's the
> critical point. I don't think they are idiots *because* they are
> unpatriotic; I think they are unpatriotic *because* they are idiots.
> The former would constitute simple-minded patriotism -- "My country,
> right or wrong." The latter constitutes intelligent patriotism -- "My
> country *is* right this time."

Both mean same thing.  "unpatriotic because idiots " are true only if 
1:there are no patriotic idiots.(if false,idiot may be patriotic)
2:all idiots are unpatriotic.(same)
are true.

 "idiots because unpatriotic" are true only if 
2:all idiots are unpatriotic.
(does not rely on "there are no patriotic idiots.".If all peoples are
idiots,"idiots because unpatriotic" right as well as "idiots because
humans")

So "unpatriotic because idiots" is a more bad expression.

I think,there are existant patriotic idiots as well as unpatriotic
ones.
So IMO,"they are unpatriotic *because* they are idiots" is a wrong
expression,because there are many patriotic idiots.


In any case,it's not about your +=. In += you're referring to 98% to
prove that += is good.Or,to prove that += is good,you're referring to
98%.
You're referring to surely correct thing(98%) to prove non-surely
correct one.And in "unpatriotic because idiots " both
things(unpatriotic and idiots)aren't surely true for me.

> 
> Whenever someone criticizes the idiot protestors, the liberal media is
> usually there to subtly imply that it is due to the simple-minded sort
> of patriotism. But usually it isn't.
> 
> I hope I made my point (considering how much time I just wasted on
> this post!).
Yes,now i understand. 
I _SPECIALLY_ readed book about marketing lingvo-psychology ;-).

We have two things:A and B.
And A is a well-known thing that don't need to be proved,and B need to
be proved.
Normally,i would write "because A,B",that truly explain my point of
view.

But if i will use form "because B,A", i'm deriving A,thing that don't
need to be proved from B that really need to be proved,to say "if B is
true,well-known A is right"(it only proves that my B can co-exist with
A).
It's simply speculation to use it as argumebt why B is true.

"Because all cubes of real values is positive,r^6 is positive."
where "all real values is positive" is a wrong thing that are
"proved":
in logically correct way :right thing(r^6 >= 0) are derived from wrong
thing.

If i will derive right thing,it does not mean that "source" are right
too.
You want to derive that "+= is a good thing" from "98%"
And you're using thing that NEED to be proved to derive that "98%
using it".
You're proved that if statement "+= is a good thing" is true,"98%" are
true too.

But to go really mathematical way, you're need to prove that if
statement "+= is a good thing" is _false_, "98% uses it" are false
too.

Example:
If there are existant most biggest number, mbn+1 = mbn. 

We really can "derive" right things from wrong ones.And it's why there
are no difference in "a is good,because b",and "b is good,because a"
:we always hear from TVs:
"because our product is good,lot of peoples worldwide uses it" it's
mean
"lot of peoples worldwide uses it,so you should think that our product
is good".

You're referring to 98% in both cases,so there are no difference how
do you arrange words.

You're saying "98% uses it because it's good",and it's mean that
you're think_that_it's_good because 98% uses it.


you're talking about "unpatriotic idiots" because they are
unpatriotic,
and i think so because you're does not talking about other idiots, the
subject are "patriotism",not "idiotism".If subject are "idiotism",it's
from "comp.sci.med".

> > We are talking about fact that infix procedures are more readable,
> > comparing a:+b with inc(a,b) ,right? What it have to do with
> > efficiency?
> 
> I've explained this ad nauseum already, so I'll just sum it up. For
> user-defined types (vectors and matrices, for example), the augmented
> assignment operators allow the programmer to define in-place
> operations that do not need temporaries and extra copying as the
> standard math operators do.
> 
> Consider the common operation of scaling a vector, for example. I
> could write
> 
>    vec := vec * factor
> or
>    vec :* factor
Explaining  Nth time:
you're have problems because a*b<?>b*a.
I don't:

function mult(in a,b:matrix):matrix;

procedure multleft(in out a:matrix;in b:matrix);
procedure multright (in a:matrix;in out b:matrix);
both calculates a*b and one stores result in a,another in b.

I really have such procedures to work with 3d graphics.
:X have nothing with efficiency because i always can use
doXinleftplace(a,b);
where doXinleftplace is a procedure.
ADA already have "augmented assignment" because ada have "in
out"!!!!!!!!!!

> 
> The first form requires the construction of a temporary, the actual
> scaling operation, then the copying back of the temporary to the
> original vector. The latter, on the other hand, can be written to
> avoid the construction of the temp and the copying back.
> 
> And yes, it is possible for a "smart" compiler to automatically
> implement the former with the efficiency of the latter, but current
> compilers don't, and more complicated examples would be *extremely*
> difficult for the compiler to optimize.
N'th time:
there are not a war with 
a:=a+b;
and a:+b;
There are war between
inc(a,b);
and
a:+b;
Inc(a,b) and a:+b are the same things for compiler!

Re: += in ada

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
: I think those protestors are unpatriotic idiots. But here's the
: critical point. I don't think they are idiots *because* they are
: unpatriotic; I think they are unpatriotic *because* they are idiots.

Let me try to paraphrase.
I think those against :+ are unfashionate fools. But here's the
critical point. I don't think they are fools *because* they are
unfashionate; I think they are unfashionate *because* they are fools.

I have a question. I don't know English so well, and I'm trying
to find the exact references for "*because*". So do you claim any of the
following to be true:
- the non-:+ are fools, therefore they are unfashionate
- the non-:+ are unfashionate, therefore they are fools.
  (Thus, being fashionate (or modern) implies being smart?)
- the reason for my thinking that the non-:+ are unfashionate is that
  the non-:+ are fools.

The fashion tells the smart ones from the fools? How is that?


If, by analogy, you

- start out with a causal claim that idiots must be unpatriotic,
  when in fact mental sanity and patriotic feelings might just
  prove to be unrelated, and then go on and say that

- those who don't have patriotic feelings must be idiots,

there is no point in arguing this analogy because there is no common
basis for argument. If you don't accept that idiocy and patriotism
might not have anything to do with each other, the non-:+ (protesters)
might say whatever they want. As long as you start from "non-:+ is
idiocy", what can we talk about, when talking reasonably is, by definition,
not easily done by idiots?


:>  What it have to do with
:> efficiency?
: 
: I've explained this ad nauseum already,

And the details seem to have slipped, now and again.

: And yes, it is possible for a "smart" compiler to automatically
: implement the former with the efficiency of the latter, but current
: compilers don't, and more complicated examples would be *extremely*
: difficult for the compiler to optimize.

There has been a somewhat "ancient" posting, re-sent a few days
ago, proving the opposite.


Georg

Re: += in ada

[Russ]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<bmn02h$jev$1@a1-hrz.uni-duisburg.de>...
> Russ <18k11tm001@sneakemail.com> wrote:
> : I think those protestors are unpatriotic idiots. But here's the
> : critical point. I don't think they are idiots *because* they are
> : unpatriotic; I think they are unpatriotic *because* they are idiots.
> 
> Let me try to paraphrase.
> I think those against :+ are unfashionate fools. But here's the
> critical point. I don't think they are fools *because* they are
> unfashionate; I think they are unfashionate *because* they are fools.

You're taking my example way too far. Let me put it this way: I don't
think they are wrong *because* they disagree with 98% of programmers;
I think they disagree with 98% of programmers *because* they are wrong
(on this particular matter).

> I have a question. I don't know English so well, and I'm trying
> to find the exact references for "*because*". So do you claim any of the
> following to be true:
> - the non-:+ are fools, therefore they are unfashionate
> - the non-:+ are unfashionate, therefore they are fools.
>   (Thus, being fashionate (or modern) implies being smart?)
> - the reason for my thinking that the non-:+ are unfashionate is that
>   the non-:+ are fools.

I never claimed any of those. By the way, the word is "unfashionable",
and I never used it. Nor did I ever call *everyone* who doesn't want
":+" fools.

> The fashion tells the smart ones from the fools? How is that?

Sometimes the minority is right and the majority is wrong, but usually
it's the other way around. For example, some people believe the earth
is flat, but most believe it is roughly spherical. I think the
majority is right in that case. However, I don't think they are right
*because* they hold the majority view; I think they hold the majority
view *because* they are obviously right. The "burden of proof" falls
naturally on the minority. If you think the earth is flat, go ahead
and try to prove it. Until you do, I'll stick with the majority.

Re: += in ada

[sk]

18k11tm001@sneakemail.com:
 > ... 98% of programmers; ...

Where did you come by that statistic ?

I think this is the third year in a row that you have
proposed the "augmented" operators isn't it ?

Would it be safe to say that 98% of Ada programmers
are not interested ?

And if this is so, can you not accept that the CLA
netizens are not particularly interested in your
proposed augmented operators ?

 > ... Nor did I ever call *everyone* who doesn't want ":+" fools.

Your tone does suggest that you think that all who do not agree
are fools :-)

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[Russ]

sk <noname@myob.com> wrote in message news:<mailman.104.1066359213.25614.comp.lang.ada@ada-france.org>...
> 18k11tm001@sneakemail.com:

> And if this is so, can you not accept that the CLA
> netizens are not particularly interested in your
> proposed augmented operators ?

"My" augmented assignment operators? No, I'm just a messenger from the
outside world. Check it out sometime.

>  > ... Nor did I ever call *everyone* who doesn't want ":+" fools.
> 
> Your tone does suggest that you think that all who do not agree
> are fools :-)

No, I just think they are missing out on an elegant programming
convenience, and they are rejecting a standard notation in favor of a
hodge-podge of awkward procedure names. As I have tried to explain
before, it's not a big thing, but I think it's a significant little
thing. And yes, little things *can* be significant.

Re: += in ada

[sk]

Russ <18k11tm001@sneakemail.com>:

 > ... <snip> ...

You still havn't provided "REAL" data to establish
the 98% claim.



-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[Dmytry Lavrov]

sk <noname@myob.com> wrote in message news:<mailman.107.1066389468.25614.comp.lang.ada@ada-france.org>...
> Russ <18k11tm001@sneakemail.com>:
> 
>  > ... <snip> ...
> 
> You still havn't provided "REAL" data to establish
> the 98% claim.

But he provided why he think that 98% :

" What I am claiming is that 98% of programmers use them *because*
they are a good idea."

;-)

But new question to Russ is "why did you think that += is a good
idea?"
Russ,please reply to _this_ question, if you can.

Dmytry Lavrov.

Re: += in ada

[Chad R. Meiners]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0310161837.7efd9995@posting.google.com...
> Sometimes the minority is right and the majority is wrong, but usually
> it's the other way around.

Really?  I have observed that the majority often believes what is convenient
as opposed to what is true.  For instance the majority of drivers believe
that they are above average drivers.

> For example, some people believe the earth
> is flat, but most believe it is roughly spherical. I think the
> majority is right in that case.

The majority use to believe that the earth was flat.

>  However, I don't think they are right
> *because* they hold the majority view; I think they hold the majority
> view *because* they are obviously right.

It is an error to view "the majority" as an entity

> The "burden of proof" falls
> naturally on the minority.

The burden of proof falls naturally on those who assert. It does not matter
whether this person belongs to the majority or the minority.

>  If you think the earth is flat, go ahead
> and try to prove it. Until you do, I'll stick with the majority.

Would it not be better to stick with evidence as oppose to the (often
incorrect) opinion of the majority?

Re: += in ada

[Preben Randhol]

On 2003-10-17, Russ <18k11tm001@sneakemail.com> wrote:
> I think they disagree with 98% of programmers *because* they are wrong
> (on this particular matter).

I also think that the 98% of programmers are wrong. :-)

Re: += in ada

[Dmytry Lavrov]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0310161837.7efd9995@posting.google.com>...
> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<bmn02h$jev$1@a1-hrz.uni-duisburg.de>...
> > Russ <18k11tm001@sneakemail.com> wrote:
> > : I think those protestors are unpatriotic idiots. But here's the
> > : critical point. I don't think they are idiots *because* they are
> > : unpatriotic; I think they are unpatriotic *because* they are idiots.
> > 
> > Let me try to paraphrase.
> > I think those against :+ are unfashionate fools. But here's the
> > critical point. I don't think they are fools *because* they are
> > unfashionate; I think they are unfashionate *because* they are fools.
> 
> You're taking my example way too far. Let me put it this way: I don't
> think they are wrong *because* they disagree with 98% of programmers;
> I think they disagree with 98% of programmers *because* they are wrong
> (on this particular matter).
Wrong.Even my english is good enought to understand why.
Your post should REPLY to "default question": 
Why they are idiots?
"I think they are unpatriotic *because* they are idiots."
-is not an answer to the question why they are idiots,it's answer to 
"they are unpatriotic?".

Why did you like +=?
"i think,98% uses it because += is good"
is an answer to the other question,"are 98% uses it?",not to given
question.

Your phrases are simply out-of-subject!

And more,
sentence
"they are unpatriotic *because* they are idiots."
are right(does mean something) when 2 things are right:
1:all idiots are unpatriotic (else there maybe patriotic idiots,and
tey may be patriotic even if they are idiots,so there should be
another reason to be unpatiotic)
2:all patriots are not idiots.(from first)

"they are idiots *because* they are unpatriotic"
are right only when 
1:all unpatriotics are idiots.
and may be right even if patriotics are idiots too.



I think,that Iraq War are war-for-oil,
and i think so _because_(i.e. i derived my point of view from fact
that-) Iraq was attacked instead of North Korea.
But also,
i think that, Iraq was attacked instead of North Korea(fact) because
it's war-for-oil(not a fact).
But i don't 
"i think that Iraq was attacked instead of North Korea and i think so
because it's war-for-oil"
because i have "Iraq was attacked instead of North Korea" as
well-known fact,and "it's war for oil?" as a question.

And
"i think that Iraq was attacked instead of North Korea and i think so
because it's war-for-oil"
is a reply to the other question,"iraq was attaked instead of north
korea?"
,and normal reply is "it's fact"

"i think so _because_(i.e. i derived my point of view from) Iraq was
attacked instead of North Korea. "
are reply "why did i think that it's war for oil".


Dmytry Lavrov.
http://DmytryLavrov.narod.ru/voxfoge.htm 
Voxel 3d light in 3d fog,above fractal landscape.

Re: += in ada

[Chad R. Meiners]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0310141000.681da5c@posting.google.com...
> The only rational reply I have received so far is that augmented
> assignment operators are too much effort to implement. Well, they
> obviously weren't too much effort for C, C++, Java, Perl, and Python.
> It's really too bad that Ada is so strapped for support. That obvously
> doesn't bode well for the future of Ada.

Could you please explain why a generic package that defines augmented
assignment procedures for a numeric type (Add, Subtract, Multiply, Divide)
is not sufficient?  I must admit that I have never felt the need for
augmented assignment, though.

-CRM

Re: += in ada

[Robert A Duff]

"Chad R. Meiners" <crmeiners@hotmail.com> writes:

> "Russ" <18k11tm001@sneakemail.com> wrote in message
> news:bebbba07.0310141000.681da5c@posting.google.com...
> > The only rational reply I have received so far is that augmented
> > assignment operators are too much effort to implement. Well, they
> > obviously weren't too much effort for C, C++, Java, Perl, and Python.
> > It's really too bad that Ada is so strapped for support. That obvously
> > doesn't bode well for the future of Ada.
> 
> Could you please explain why a generic package that defines augmented
> assignment procedures for a numeric type (Add, Subtract, Multiply, Divide)
> is not sufficient?

Because you have to instantiate the doggone thing for every integer type
where you might want to do Add.  And you have to anticipate which types
those are, or else do it when it's unnecessary.  It leads to a lot of
useless (unreadable) clutter in the code.  So nobody bothers with that;
we all just write X := X + 1, even when X is slightly complicated.

- Bob

Re: += in ada

[Chad R. Meiners]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccsmlodbyh.fsf@shell01.TheWorld.com...
> Because you have to instantiate the doggone thing for every integer type
> where you might want to do Add.  And you have to anticipate which types
> those are, or else do it when it's unnecessary.  It leads to a lot of
> useless (unreadable) clutter in the code.  So nobody bothers with that;
> we all just write X := X + 1, even when X is slightly complicated.

What is so wrong with something like?

   type My_Numbers is range 0..255;
   package Augmented_My_Numbers is new Augmented_Assignments(My_Numbers);

with an optional

   use Augmented_My_Numbers;

So there isn't that much clutter.  However, I do agree that

Re: += in ada

[Alexander Kopilovitch]

Lutz Donnerhacke wrote:
>  declare
>     a : Typ renames X(b(i).all + 7);
>  begin
>     a := a + 2/a;
>  end;
>
>  is legal Ada and a common idiom.
>
>  ...
>
>  So I have to conlude, that the whole "idem" Idiom is useless at all.

But "idem" require neither identifier nor declare-begin-end, and it is purely
local. Sometimes it is better to use renaming, but far from always - there are
enough cases where "idem" is better... and more natural. Use of renaming here
is just a middle of the spectre of solutions, where one edge is a function
returning access (which is generally more burdensome in Ada than in C) and
another edge is "idem".



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: += in ada

[Dmytry Lavrov]

aek@vib.usr.pu.ru (Alexander Kopilovitch) wrote in message news:<e2e5731a.0310071028.7a742311@posting.google.com>...
> Lutz Donnerhacke wrote:
> >  declare
> >     a : Typ renames X(b(i).all + 7);
> >  begin
> >     a := a + 2/a;
> >  end;
> >
> >  is legal Ada and a common idiom.
> >
> >  ...
> >
> >  So I have to conlude, that the whole "idem" Idiom is useless at all.
> 
> But "idem" require neither identifier nor declare-begin-end, and it is purely
> local. Sometimes it is better to use renaming, but far from always - there are
> enough cases where "idem" is better... and more natural. Use of renaming here
> is just a middle of the spectre of solutions, where one edge is a function
> returning access (which is generally more burdensome in Ada than in C) and
> another edge is "idem".
> 
> 
> 
> Alexander Kopilovitch                      aek@vib.usr.pu.ru
> Saint-Petersburg
> Russia

i have a question about

 a : Typ renames X(b(i).all + 7);
  begin
     a := a + 2/a;
 end;

it's possible to include it into code?

begin
......something... ;
a : Typ renames X(b(i).all + 7);--if possible, are this ; is a mistake
or it's breaks all pascal "laws"?
  begin
     a := a + 2/a;
 end;
.......something.........
end;

Yes,main problem with this that it's too long,more and more shugar are
proposed.
...
Ohh,why we don't have = with 3 lines in ASCII character set,just for
nice smileys =_),for example,
a=_ X(b(i).all + 7) in   a := a + 2/a; looks better.

(main problem that "in" is a relational operator,but still be
understandable,and IMO better than all possible sorts of ..bad russian
qword.. to make code more "readable")

"=_" mean "= with 3 lines"

Or maybe haskell-like
 a := a + 2/a where a=_ X(b(i).all + 7);
(IMO not so good).

Another question:

why all these stu... still want +=, /= and \=,with nice >=,<=,
juliafractal= and i-don-know-what-sort-of-idiotism with *= where a*b
?/= b*a ?
(and ?/= is a pseudo-operator "unequal,maybe")

Why beginner like me are interested in this subject:
I don't want to spend my time learning language that will be c-like in
near future,and then will die because c will always be more c-like
than ada!.
Heh, even beginner,coming from FreePascal,where "+=" are supported, 
don't want "+=" in Ada!!!

Dmytry Lavrov,

http://DmytryLavrov.narod.ru

idem (Was: += in ada)

[Jacob Sparre Andersen]

Preben Randhol wrote:

> The problem I have with idem is that it looks like just another
> variable.

Yes.  But it is a cool idea.  And with a suitable idem marker, I think
it would make it possible to write even more readable code.  Also,
"idem" doesn't look any more like another variable than the operators
"and", "or" and "not".

What I worry most about with idem is that it would make the expression
syntax used in assignments different from that used in other places.

Jacob
-- 
"... while the C compiler will happily generate code for
  almost anything produced by leaning on the keyboard."

Re: idem (Was: += in ada)

[Dmitry A. Kazakov]

On Mon, 20 Oct 2003 09:41:39 +0200, Jacob Sparre Andersen
<sparre@crs4.it> wrote:

>Preben Randhol wrote:
>
>> The problem I have with idem is that it looks like just another
>> variable.
>
>Yes.  But it is a cool idea.  And with a suitable idem marker, I think
>it would make it possible to write even more readable code.  Also,
>"idem" doesn't look any more like another variable than the operators
>"and", "or" and "not".
>
>What I worry most about with idem is that it would make the expression
>syntax used in assignments different from that used in other places.

Probably there could be a generalization. Consider assignment as a
procedure:

procedure ":=" (Idem : in out Type; Right : Type);

Then in

X := Idem + 1;

Idem would be just the name of a formal parameter. This could be
applicable to all kinds of subroutines. Of course, a direct use of a
parameter name would lead to possible name clashes. So it would be
better to have a special notation to access the parameter names as
"=>" does. For example:

X := ":=".Idem + 1;

It looks extremely ugly, but illustrates the idea. So for a function
Mean one could write something as unreadable as:

X := 
   Mean
   (  Left => Some_Awfully_Complex_Expression,
      Right => Mean.Left * 3.0
   );

This would also impose additional requirements on parameter evaluation
order. Or else, allow excellent:

Mean (Left => Mean.Right, Right => Mean.Left);

All C++ programmers will immediately switch to Ada, to have this!
(:-))

--------
In one of previous incarnations of this ever lasting thread there was
made a better proposal for idem. We could allow loop labels for the
assignment statement:

[ <label> : ] <target> := <expression>;

So:

Idem : X := Idem + 1;

which would be an abbreviation of:

declare
   Idem : X_Type renames X;
begin
   Idem := Idem + 1;
end;

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: idem (Was: += in ada)

[(see below)]

On 20/10/03 08:41, in article 3F9391B3.1080001@crs4.it, "Jacob Sparre
Andersen" <sparre@crs4.it> wrote:

> What I worry most about with idem is that it would make the expression
> syntax used in assignments different from that used in other places.


That's true, but I don't worry about it.
Assignments *are* different from the other places expressions are used.

-- 
Bill

Re: idem (Was: += in ada)

[Nick Roberts]

Jacob Sparre Andersen wrote:

> Preben Randhol wrote:
> 
>> The problem I have with idem is that it looks like just another
>> variable.
> 
> Yes.  But it is a cool idea.  And with a suitable idem marker, I think
> it would make it possible to write even more readable code.  Also,
> "idem" doesn't look any more like another variable than the operators
> "and", "or" and "not".
> 
> What I worry most about with idem is that it would make the expression
> syntax used in assignments different from that used in other places.

What if we only changed the syntax of the assignment statement?

Change RM95 5.2(2) to:

    assignment_statement ::=
       explicit_assignment_statement
     | implicit_assignment_statement

    explicit_assignment_statement ::=
       variable_name := expression;

    implicit_assignment_statement ::=
       variable_name :=
          ALL binary_adding_operator term
          {binary_adding_operator term};

I've used the reserved word 'all' here, since I think it serves the purpose 
and saves introducing a new reserved word.

This formulation adds some complexity to the definition of the assignment 
statement in the RM, but it avoids changing expressions in any way. Just a 
thought.

-- 
Nick Roberts

Re: += in ada

[Stuart Palin]

Regarding this vociferous debate on the matter of operators
such as ":+=" (or however you choose to denote it).

May I ask how it might be squared with the ability to
declare and rename other operator functions and using such
operators in a post-fix fashion.

In the moments of idle curiosity I have given to the matter
the only reasonable interpretation would seem to be to treat
them not as specific operators in their own right, but as a
syntactic equivalent to the use of a more basic operator.

e.g.  a :+= b;  is equivalent to a := a + b;

Then any redefinition of "+" is inherited by ":+=".  But
this does not necessarily help clarify any post-fix form of
the operator.

Treating them as operator functions in their own right seems
to create difficulties in defining a workable specification
for the function or leads to the possibility of
"interesting" expressions such as:
  a :+= ":+="(b, c);

I presume that it might be treated like any other function
(where an exception may be raised during execution) - but
that seems to lead us into one of the other arguments
debated elsewhere (should LHS be updated/unaffected if there
is an exception).

If the post-fix form (or multiple infixed operators) were
allowed, would any special precautions be needed for
"pathological" cases.  (I'm thinking of code like:

  a :+= ":+="(a, a);
)

I suppose the other option would be to treat them not as
operators but as "assignments" (and so not support renaming
on post-fix notation) - but there seems to be a tendency in
these threads to refer to them as "operators".

--
Stuart Palin

Re: += in ada

[Russ]

Stuart Palin <stuart.palin@0.0> wrote in message news:<3F8BC74F.2CFBFF37@0.0>...
> Regarding this vociferous debate on the matter of operators
> such as ":+=" (or however you choose to denote it).
> 
> May I ask how it might be squared with the ability to
> declare and rename other operator functions and using such
> operators in a post-fix fashion.
> 
> In the moments of idle curiosity I have given to the matter
> the only reasonable interpretation would seem to be to treat
> them not as specific operators in their own right, but as a
> syntactic equivalent to the use of a more basic operator.
> 
> e.g.  a :+= b;  is equivalent to a := a + b;
> 
> Then any redefinition of "+" is inherited by ":+=".  But

Actually, a competent programmer will define the "+" operator in terms
of the ":+" operator rather than vice versa, because the ":+" is
usually more efficient (since it has no need for temporaries and extra
copying).

> this does not necessarily help clarify any post-fix form of
> the operator.

> Treating them as operator functions in their own right seems
> to create difficulties in defining a workable specification
> for the function or leads to the possibility of
> "interesting" expressions such as:
>   a :+= ":+="(b, c);

Actually, the augmented assignment operators are symbolic of
procedures rather than functions. They should not return anything.
(They can return something in C++, but thats only because C++, like C,
does not distinguish between functions and procedures.)

Re: += in ada

[Lutz Donnerhacke]

* Russ wrote:
> Actually, a competent programmer will define the "+" operator in terms
> of the ":+" operator rather than vice versa, because the ":+" is
> usually more efficient (since it has no need for temporaries and extra
> copying).

Wrong.

Re: += in ada

[Hyman Rosen]

Lutz Donnerhacke wrote:
> * Russ wrote:
>>Actually, a competent programmer will define the "+" operator in terms
>>of the ":+" operator rather than vice versa, because the ":+" is
>>usually more efficient (since it has no need for temporaries and extra
>>copying).
> 
> Wrong.

That's certainly the way it's usually done in C++,
for exactly the reason stated, so a bald "wrong" is
not terribly enlightening.

Re: += in ada

[Mark A. Biggar]

Hyman Rosen wrote:

> Lutz Donnerhacke wrote:
> 
>> * Russ wrote:
>>
>>> Actually, a competent programmer will define the "+" operator in terms
>>> of the ":+" operator rather than vice versa, because the ":+" is
>>> usually more efficient (since it has no need for temporaries and extra
>>> copying).
>>
>>
>> Wrong.
> 
> 
> That's certainly the way it's usually done in C++,
> for exactly the reason stated, so a bald "wrong" is
> not terribly enlightening.
> 

Okay, show how to define "+" in terms of "+=" with out explicitly
reintroducing the temp variable you were so hot to eliminate?

-- 
mark@biggar.org
mark.a.biggar@comcast.net

Re: += in ada

[Hyman Rosen]

Mark A. Biggar wrote:
> Okay, show how to define "+" in terms of "+=" with out explicitly
> reintroducing the temp variable you were so hot to eliminate?

"I" am not hot to eliminate anything. But you seem to miss the point entirely.
In C++, I can say A += B, and then I don't need the temporary. If I say A = B + C,
then I do. But Ada forces you to say A = A + b for the first case, and that gives
you the temporary that you don't need.

Re: += in ada

[Robert I. Eachus]

Hyman Rosen wrote:

> In C++, I can say A += B, and then I don't need the temporary. If I say 
> A = B + C, then I do. But Ada forces you to say A = A + b for the first
>  case, and that gives you the temporary that you don't need.

Which makes Ada better for most common CPUs today, right?  In a 
processor with register renaming and OoO execution, which all Pentiums 
since the Pentium Pro and all Celerons, Athlons, and Durons have, 
register pressure can be caused by a lack of register names, but not 
registers.  So in (pseudo)code like
    load R1,A
    add R1,B
    store R1,A
the CPU will actually use a pair of renaming registers to represent R1 
in this code fragment.  And no matter whether you use the "Ada" approach 
or the "C++" approach to defining the sequence, you will still use two 
renaming registers and one register name to implement the code.  (Oh, 
and the time to execute the code will probably be dominated by the time 
to fetch A and B if they are not already in registers or L1 cache.)

Modern CPUs are so far from the finite state machines you may have been 
taught about in some Assembler class that it isn't even funny.  I 
usually say that modern processors have lots of circutry devoted to 
confusing anyone who tries to debug software using a debugger.  The 
problem is not just that the states you see in the debugger don't exist 
when your code is running normally, no states corresponding to the ISA 
exist when the processor is running normally.  In fact, no states at all 
exist when the processor is running.  If you tell the processor to 
create some sort of a state and push it on the stack it will do that. 
Just remember that the state you see was manufactured this way because 
you asked the processor to do so.
-- 
                                        Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Marin David Condic]

And don't forget to mention that 99% of applications will *never* notice 
the difference if a temoprary is created or not. Most things just simply 
are not so time-bound that a couple of extra microseconds (or is it 
nanoseconds these days? Picoseconds? Femptoseconds? Attoseconds? :-) 
burnt up in building and discarding some temporary - if in fact it does 
get created - are going to go totally unnoticed. And when we're getting 
main memory measured in *gigabytes* these days, can we really gripe 
about the space allocated? If the only thing at stake here is the 
relative efficiency between A += B and A := A + B then lets move on to 
something *really* interesting - like how waxing your car will gain you 
more fuel efficiency and save you Big Money at the gas pump every week.

So tossing out efficiency as a concern, about all that is left is 
"style" to care about. Some folks may prefer staring at A += B rather 
than A := A + B - and such is their right. But many of us who grew up on 
Pascal, Fortran and Ada never found it to so wonderfully attractive that 
we just had to have it at any price. So we don't have any universal 
consensus that a) the "+=" if significantly more beautiful than the 
usual form, b) enough people find it to be so beautiful that Ada just 
*has* to go out there and implement it and c) once it makes it into the 
language the herds of C/C++/Java programmers will suddenly drop their 
opposition to Ada and get on board with the language. It just doesn't 
seem like its worth disrupting the compiler writers to get it in the 
language - or inconveniencing as many electrons as have been done in 
this thread over it.

The difference between A += B and A := A + B doesn't amount to a warm 
bucket of spit. I'd suggest looking for where Ada has real shortcomings 
that need attention.

MDC


Robert I. Eachus wrote:
> Hyman Rosen wrote:
> 
>> In C++, I can say A += B, and then I don't need the temporary. If I 
>> say A = B + C, then I do. But Ada forces you to say A = A + b for the 
>> first
>>  case, and that gives you the temporary that you don't need.
> 
> 
> Which makes Ada better for most common CPUs today, right?  In a 
> processor with register renaming and OoO execution, which all Pentiums 
> since the Pentium Pro and all Celerons, Athlons, and Durons have, 
> register pressure can be caused by a lack of register names, but not 
> registers.  So in (pseudo)code like
>    load R1,A
>    add R1,B
>    store R1,A
> the CPU will actually use a pair of renaming registers to represent R1 
> in this code fragment.  And no matter whether you use the "Ada" approach 
> or the "C++" approach to defining the sequence, you will still use two 
> renaming registers and one register name to implement the code.  (Oh, 
> and the time to execute the code will probably be dominated by the time 
> to fetch A and B if they are not already in registers or L1 cache.)
> 
> Modern CPUs are so far from the finite state machines you may have been 
> taught about in some Assembler class that it isn't even funny.  I 
> usually say that modern processors have lots of circutry devoted to 
> confusing anyone who tries to debug software using a debugger.  The 
> problem is not just that the states you see in the debugger don't exist 
> when your code is running normally, no states corresponding to the ISA 
> exist when the processor is running normally.  In fact, no states at all 
> exist when the processor is running.  If you tell the processor to 
> create some sort of a state and push it on the stack it will do that. 
> Just remember that the state you see was manufactured this way because 
> you asked the processor to do so.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Chad R. Meiners]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F8F4559.50306@noplace.com...
> than A := A + B - and such is their right. But many of us who grew up on
> Pascal, Fortran and Ada never found it to so wonderfully attractive that
> we just had to have it at any price.

Don't forget those of use who grew up on BASIC. ;-)

Re: += in ada

[Marin David Condic]

O.K. Basic too. (Been there. Done that. The first language I ever used - 
on a DECSystem 10, no less. With 110 baud teletypes.)

Keep in mind the key point that not everyone finds it "attractive" (I 
don't) and that its not buying a whole lot of improvement on anything, 
and since there are limited resources for modifying the Ada standard, 
this pretty much is a non-starter. There are bigger fish to fry.

MDC



Chad R. Meiners wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F8F4559.50306@noplace.com...
> 
>>than A := A + B - and such is their right. But many of us who grew up on
>>Pascal, Fortran and Ada never found it to so wonderfully attractive that
>>we just had to have it at any price.
> 
> 
> Don't forget those of use who grew up on BASIC. ;-)
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3F8FD877.4020101@noplace.com>...
> O.K. Basic too. (Been there. Done that. The first language I ever used - 
> on a DECSystem 10, no less. With 110 baud teletypes.)
> 
> Keep in mind the key point that not everyone finds it "attractive" (I 
> don't) and that its not buying a whole lot of improvement on anything, 
> and since there are limited resources for modifying the Ada standard, 
> this pretty much is a non-starter. There are bigger fish to fry.

As a promoter of Ada, I'm more worried about *getting* fried than I am
about what to fry.

Re: += in ada

[Wes Groleau]

Chad R. Meiners wrote:
> Don't forget those of use who grew up on BASIC. ;-)

I think I had to _leave_ Basic in order to grow up.

-- 
Wes Groleau
Can we afford to be relevant?
http://www.cetesol.org/stevick.html

Re: += in ada

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3F8F4559.50306@noplace.com>...
> And don't forget to mention that 99% of applications will *never* notice 
> the difference if a temoprary is created or not. Most things just simply 
> are not so time-bound that a couple of extra microseconds (or is it 
> nanoseconds these days? Picoseconds? Femptoseconds? Attoseconds? :-) 
> burnt up in building and discarding some temporary - if in fact it does 
> get created - are going to go totally unnoticed. And when we're getting 
> main memory measured in *gigabytes* these days, can we really gripe 
> about the space allocated? If the only thing at stake here is the 
> relative efficiency between A += B and A := A + B then lets move on to 
> something *really* interesting - like how waxing your car will gain you 
> more fuel efficiency and save you Big Money at the gas pump every week.

Oh, I see. So efficiency is no longer an issue. Well, excuse me, but I
think we'd be better off leaving that judgment to each application
developer. Controlling a building temperature is one thing, but
delivering a cruise missile to Saddam Hussein's front door is quite
another.

Do you have any idea whatsoever how much computation is potentially
involved in computing optimal conflict-free trajectories for thousands
of airplanes? Here's a suggestion: if you don't know WTF you are
talking about, STFU.

> So tossing out efficiency as a concern, about all that is left is 
> "style" to care about. Some folks may prefer staring at A += B rather 
> than A := A + B - and such is their right. But many of us who grew up on 
> Pascal, Fortran and Ada never found it to so wonderfully attractive that

Oh, isn't that wonderful. Pascal, Fortran, and Ada. Did you contribute
your "wisdom" to the demise of Pascal and Fortran too? I guess you're
going for the trifecta with Ada, eh? Ever heard of "three strikes and
you're out"?

> we just had to have it at any price. So we don't have any universal 
> consensus that a) the "+=" if significantly more beautiful than the 
> usual form, b) enough people find it to be so beautiful that Ada just 
> *has* to go out there and implement it and c) once it makes it into the 
> language the herds of C/C++/Java programmers will suddenly drop their 
> opposition to Ada and get on board with the language. It just doesn't 
> seem like its worth disrupting the compiler writers to get it in the 
> language - or inconveniencing as many electrons as have been done in 
> this thread over it.
> 
> The difference between A += B and A := A + B doesn't amount to a warm 
> bucket of spit. I'd suggest looking for where Ada has real shortcomings 
> that need attention.

Oh, so let's neglect the little things and focus on the big things.
Here's a little piece of wisdom for you: if you don't bother getting
the little things right, you probably won't get the big things right
either.

Re: += in ada

[sk]

Russ <18k11tm001@sneakemail.com>:

 > Oh, I see. So efficiency is no longer an issue. Well, ...
 > ... <snip> ...
 > talking about, STFU.

What has this to do with whether "augmented" operators
are useful to a programming language or not ?

If I am not mistaken, a hell of a lot of cruise missile
control is written in Ada anyway; so is airtraffic control
software.

I still want to know where you get your 98% from ?

If I google for "+programming +language +usage", I find
absolutely nothing which would suggest that 98% of programmers
hate Ada because it does not have "augmented" operators.

The only web page I found of interest and absolutely pertinent
to "programming language usage" was

"http://archive.adaic.com/docs/lang_survey/html/4.htm"
(sadly not guaranteed to be unbiased since it as at AdaIC)

which shows that there are more lines of Ada code than "C"
code in Weapon Systems (which tends to support my earlier claim)
and therefore there is no way in hell that 98% of code uses
"augmented" operators.

PLEASE DO NOT MAKE CLAIMS, SUCH AS 98% OF ANYTHING, WITHOUT
SUPPORTING DATA !

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[Preben Randhol]

On 2003-10-19, Russ <18k11tm001@sneakemail.com> wrote:
> of airplanes? Here's a suggestion: if you don't know WTF you are
> talking about, STFU.

I wish you could do that until you have taken a course on manners.

Preben
-- 
"i too once thought that when proved wrong that i lost somehow"
                               - i was hoping, alanis morisette

Re: += in ada

[Marin David Condic]

Russ wrote:
 >
 >
 > Oh, I see. So efficiency is no longer an issue. Well, excuse me, but
 > I think we'd be better off leaving that judgment to each application
 > developer. Controlling a building temperature is one thing, but
 > delivering a cruise missile to Saddam Hussein's front door is quite
 > another.
 >
 > Do you have any idea whatsoever how much computation is potentially
 > involved in computing optimal conflict-free trajectories for
 > thousands of airplanes? Here's a suggestion: if you don't know WTF
 > you are talking about, STFU.
 >
I build realtime systems every day that have to manage jet engines and
do things in a 1.024 milisecond cycle. I think I know a little something
about efficiency. And having worked on the navigational aspects of the 
Ballistic Missile Defense, I think I might know a little something about 
trajectory computations too. I also know that if I *need* that level of 
efficiency, I can get it. Not necessarily in a way you will consider 
"pretty" - but in a way that I think looks just fine and works well 
without having to modify the Ada compiler to satisfy some C/C++ bigots.

If you would pay attention instead of a) being absolutely convinced of
the complete rightness of your own position and the obvious stupidity of 
anyone who disagrees with you and b) hurling insulting and vulgar 
remarks at them, you might learn something. I *said* in "99% of 
applications". *MOST* software would *NEVER* notice the difference. So 
what you're asking for is not going to make a huge difference to the 
bulk of users and for those few, rare pieces of software (such as my 
engine control) where it *might* matter, we have ways of getting it that 
are neither ugly nor inefficient.

So not only are you exhibiting profound rudeness, but also poor 
engineering judgement. You're supposed to be picking technology for the 
future?


 >
 > Oh, isn't that wonderful. Pascal, Fortran, and Ada. Did you
 > contribute your "wisdom" to the demise of Pascal and Fortran too? I
 > guess you're going for the trifecta with Ada, eh? Ever heard of
 > "three strikes and you're out"?
 >
I don't kill computer languages. Also, none of the above are dead. They 
all have their markets and satisfy them quite well. Just because some 
new language comes along that captures a large part of the market 
doesn't mean that older languages don't have a following or a large 
installed base of software or valid and useful constructs for developing 
software.

Nor does it mean that people who have ever used them are some sort of 
loosers who should be insulted in public by rude posters.

It is an interesting thesis that lack of a "+=" opwerator guarantees the 
demise of a computer language and presence of one will cause programmers 
to flock to its doors in massive numbers. Unfortunately, it is a theory 
that is blissfully unencombered with any facts. At best, you have 
"coincidence" - C/C++ are popular. C/C++ have a "+=" opwerator. The "+=" 
operator is necessary to be popular. It just doesn't logically follow.

 >
 >
 > Oh, so let's neglect the little things and focus on the big things.
 > Here's a little piece of wisdom for you: if you don't bother getting
 > the little things right, you probably won't get the big things right
 > either.

Yup. Quit worrying about the nickles and dimes and go for the things 
that have significant impact. That's pretty fundamental as a premise in 
engineering. A good engineer goes for maximum benefit for $$$ invested 
or labor expended or whatever factor is being optimized - just like a 
good businessman. An engineer who wants to improve the gas mileage he 
gets doesn't put a wax job on his SUV to reduce the air friction level - 
he buys a sub-compact. (Or at least starts stripping weight out of the 
SUV - and not just emptying the ash trays and vaccuuming the dirt out of 
the rugs.)

Maybe you might try considering that your position is not the only truly 
right position here and that all right-thinking people would naturally 
agree with you. Have a little humility and consider that there are 
*other* smart people out here who perhaps have *other* issues that this 
might impact and hence, your proposal is not gaining any traction. You 
might actually learn something about the issues that are involved in 
designing and maintaining a programming language.

Or you can just abandon any concern about Ada and go tell your boss that 
Ada is not worth using on future projects because it doesn't have a "+=" 
operator. Or, if you're so convinced of the value of this, go write a 
pre-compiler that supports it and translates it into appropriate 
procedure calls - that might be a constructive way of demonstrating that 
if Ada only had a "+=" operator, it would gain popularity. Either way. I 
don't care. I'd just suggest dropping the lobbying for it because it 
isn't going to happen.

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3F929FC8.9070901@noplace.com>...

> I build realtime systems every day that have to manage jet engines and
> do things in a 1.024 milisecond cycle. I think I know a little something
> about efficiency. And having worked on the navigational aspects of the 
> Ballistic Missile Defense, I think I might know a little something about 
> trajectory computations too. I also know that if I *need* that level of 
> efficiency, I can get it. Not necessarily in a way you will consider 
> "pretty" - but in a way that I think looks just fine and works well 
> without having to modify the Ada compiler to satisfy some C/C++ bigots.

Oh, the C/C++ "bigots" again. And what about the Java bigots, and the
Perl and Python bigots?

And if you're so tuned into efficiency, then why do you refuse to
standardize nomenclature for efficient mathematical operations? If I
want to add two matrices efficiently in Ada, I can use

  Add ( From=>A, To=>B ); -- or
  Addition ( A, Into=>B ); -- or
  Plus ( To=>B, A ); -- or
  MatrixAdd ( A, B ); -- or
  MatrixPlus ( Into=>B, From=>A ); -- or
  MatPlus ( A, inplace=>B); -- or
  MatrixAddition ( destination=>A, source=>B); -- and on and on and on

And I'll bet every one of those has been used in Ada code somewhere!
But if I want efficient matric addition in C++ there is rarely any
reason to use anything other than

  A += B; // lots of room for a comment here, but none needed!

Certainly you are not so blind and closed-minded that you cannot see
how much simpler and more standardized the C++ method is. And perhaps
you will take that into consideration next time you scratch your head
and wonder why C++ is so much more popular than Ada. No, it isn't just
bigotry.

> So not only are you exhibiting profound rudeness, but also poor 
> engineering judgement. You're supposed to be picking technology for the 
> future?

No, I'm not "picking" technology for the future ATM system. I'm
working with the top experts in the world to *develop* it. We're the
folks who are figuring out how to make use of the new CNS
(Communication, Navigation, and Surveillence) infrastructure that will
be available in the next decade or two. We're the guys who will "put
it all together". Our goal is to double or triple the capacity of the
current system without compromising safety. That will require much
more automation than is currently used. That means more
safety-critical software.

By the way, I didn't get into the position I am in by using bad
engineering judgment, and your claim that I am displaying such here is
just hot air.

> 
> 
>  >
>  > Oh, isn't that wonderful. Pascal, Fortran, and Ada. Did you
>  > contribute your "wisdom" to the demise of Pascal and Fortran too? I
>  > guess you're going for the trifecta with Ada, eh? Ever heard of
>  > "three strikes and you're out"?
>  >
> I don't kill computer languages. Also, none of the above are dead. They 
> all have their markets and satisfy them quite well. Just because some 
> new language comes along that captures a large part of the market 
> doesn't mean that older languages don't have a following or a large 
> installed base of software or valid and useful constructs for developing 
> software.

I'm well aware of all that. What concerns me is what the options will
be when the time comes to implement the high-capacity ATM system that
I help to develop.

Now, if I propose that Fortran or Pascal be used, I will be laughed
out of the room. If I push for C, C++, or Java, on the other hand, I
will be taken very seriously. Ada is on the edge, but is on the verge
of falling off the edge, of the list of serious candidates.

Every little thing that can help improve Ada's popularity without
damaging its effectiveness is critical now. If the Ada 200x design
team gets too conservative, Ada will almost certainly work its way out
of the picture.

> Nor does it mean that people who have ever used them are some sort of 
> loosers who should be insulted in public by rude posters.

I'm sure they will get over my insults.

> It is an interesting thesis that lack of a "+=" opwerator guarantees the 
> demise of a computer language and presence of one will cause programmers 
> to flock to its doors in massive numbers. Unfortunately, it is a theory

You guys must work overtime to miss the point. Did you read my little
analogy about sun visors on cars? You are precisely the salesman who
claims that visors aren't necessary because they can be constructed
easily with duct tape and cardboard.

> that is blissfully unencombered with any facts. At best, you have 
> "coincidence" - C/C++ are popular. C/C++ have a "+=" opwerator. The "+=" 
> operator is necessary to be popular. It just doesn't logically follow.

Take a look some time at comp.lang.c, comp.lang.c++, comp.lang.java.*,
comp.lang.perl, and comp.lang.python. You might just find that each of
them gets more posts in a day than comp.lang.ada gets in a month. Is
that *because* they each have "+="? I don't know, but you cannot deny
the correlation between "+=" and popularity. (Of course, they all use
"=" rather than ":=" for assignment, which may also be a huge factor,
but that's another story.)

> Or you can just abandon any concern about Ada and go tell your boss that 
> Ada is not worth using on future projects because it doesn't have a "+=" 
> operator. Or, if you're so convinced of the value of this, go write a 
> pre-compiler that supports it and translates it into appropriate 
> procedure calls - that might be a constructive way of demonstrating that 
> if Ada only had a "+=" operator, it would gain popularity. Either way. I

I might just do that. I've already written a pre-processor that
converts "=" to ":=" (or "=>", if appropriate) and eliminates the need
for semi-colons. I've tested it on about a half-dozen publicly
available Ada packages, and it works well. I even have the inverse
pre-processor that converts code the other way. When I run code
through both pre-processors I get the original code back, which is a
good sign.

My pre-processors thus implement a new dialect of Ada, which I call
"MyAda", that a programmer could conceivably use on an Ada95 team and
nobody else on the team would ever know the difference. All I need to
make it truly practical is a mechanism to do the conversions
automatically. That is, if I wish to use "MyAda", the standard Ada95
code automatically gets converted to MyAda when I check out the file,
and it gets converted back to Ada95 when I check it back in.

The problem with "+=" is that Ada 95 has no standard. Converting "+="
to "Inc" is easy enough, but how can I be sure that "Inc" is the right
procecure name? Ditto for the inverse pre-processor. How can I be sure
that "Inc" rather than "Add" gets converted to "+="? Perhaps now you
are starting to see why I like standard nomenclature so much.

> don't care. I'd just suggest dropping the lobbying for it because it 
> isn't going to happen.

I've already wasted more than enough time on this little endeavor, so
I may just take your suggestion.

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Russ wrote:

> You might just find that each of
>them gets more posts in a day than comp.lang.ada gets in a month. Is
>that *because* they each have "+="?

Well, guessing that most postings are related to language problems
this must be the case, yes. Ada doesn't have "+=", so there are less
problems => less postings.

This must be correlated to these operators. Obviously.


SCNR,

Vinzent.

Re: += in ada

[Chad R. Meiners]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0310191847.2d254e86@posting.google.com...
> Now, if I propose that Fortran or Pascal be used, I will be laughed
> out of the room. If I push for C, C++, or Java, on the other hand, I
> will be taken very seriously. Ada is on the edge, but is on the verge
> of falling off the edge, of the list of serious candidates.
>
> Every little thing that can help improve Ada's popularity without
> damaging its effectiveness is critical now. If the Ada 200x design
> team gets too conservative, Ada will almost certainly work its way out
> of the picture.

Let's see... Ada has a very nice formal subset named SPARK
(www.sparkada.com), which allows you to perform formal verification on
safety critical sections of code.  I would take the avaliability of SPARK
over the availability of augmented assignment any day.

Re: += in ada

[Marin David Condic]

Wow! There's a novel concept. "Pick a language because of engineering 
reasons like safety and verifiability rather than personal preferences 
for the way the syntax looks..." What are the odds that will catch on? :-)

MDC


Chad R. Meiners wrote:
> 
> 
> Let's see... Ada has a very nice formal subset named SPARK
> (www.sparkada.com), which allows you to perform formal verification on
> safety critical sections of code.  I would take the avaliability of SPARK
> over the availability of augmented assignment any day.
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Ross Higson]

> 
> Take a look some time at comp.lang.c, comp.lang.c++, comp.lang.java.*,
> comp.lang.perl, and comp.lang.python. You might just find that each of
> them gets more posts in a day than comp.lang.ada gets in a month. Is
> that *because* they each have "+="? I don't know, but you cannot deny
> the correlation between "+=" and popularity. (Of course, they all use
> "=" rather than ":=" for assignment, which may also be a huge factor,
> but that's another story.)

So presumably adding a C/C++ type assignment operator to Ada is going to 
be your next great crusade ?. Wonderful - then all Ada programmers could 
enjoy one of my favorite C/C++ bugs:

#include <stdio.h>
main () {
int a = 0;
if (a = 0)
    printf ("Russ has a point\n");
else
    printf ("Russ is an idiot\n");
}

I've actually seen texts that say in C++ you should always write things 
like "if (5 == b)" instead of "if (b == 5)" just in case you were to 
accidentally write "if (b = 5)". Now *there's* a language that protects 
the user from easy-to-make but hard-to-spot mistakes, and encourages 
readability into the bargain !.

> 
> I've already wasted more than enough time on this little endeavor, so
> I may just take your suggestion.

(grateful sigh from the entire newgroup readership !)

Re: += in ada

[Russ]

Ross Higson <rosshigsonREMOVE_ME@optusnet.com.au> wrote in message news:<3f937e27$0$28121$afc38c87@news.optusnet.com.au>...
> > 
> > Take a look some time at comp.lang.c, comp.lang.c++, comp.lang.java.*,
> > comp.lang.perl, and comp.lang.python. You might just find that each of
> > them gets more posts in a day than comp.lang.ada gets in a month. Is
> > that *because* they each have "+="? I don't know, but you cannot deny
> > the correlation between "+=" and popularity. (Of course, they all use
> > "=" rather than ":=" for assignment, which may also be a huge factor,
> > but that's another story.)
> 
> So presumably adding a C/C++ type assignment operator to Ada is going to 
> be your next great crusade ?. Wonderful - then all Ada programmers could 
> enjoy one of my favorite C/C++ bugs:
> 
> #include <stdio.h>
> main () {
> int a = 0;
> if (a = 0)
>     printf ("Russ has a point\n");
> else
>     printf ("Russ is an idiot\n");
> }

Someone please tell me: What is the proper response when you are
kicked in the balls by a three-foot dwarf?

Re: += in ada

[sk]

Russ <18k11tm001@sneakemail.com>:

 > Someone please tell me: What is the proper response when
 > you are kicked in the balls by a three-foot dwarf?

Walk away ! Let it drop etc. etc. etc.

PS. Since you neither confirm nor deny being the same
Russ that perpetually (since you allow yourself to use
unsupported "facts", I will use perpetually instead of
last year) brings up the absolute cure all solution
to Ada's woes as "+=", I will refer you to the other
Russ's 7 points which are guaranteed to save Ada from
joining the dinosaurs.

Visit :

"http://russp.org" (note the witty and clever intro cross
out of rantings)

Select "Features" and page down to the bottom and
see "A Cleaner Syntax for Ada Programming".

I think you, Russ <18k11tm001@sneakemail.com>, will
find a kindred spirit such that if you join together,
you will make the 98% of something be a sample set of 2
rather than you being by your lonesome for statistical
claims :-)


-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[Russ]

sk <noname@myob.com> wrote in message news:<mailman.152.1066761116.25614.comp.lang.ada@ada-france.org>...
> Russ <18k11tm001@sneakemail.com>:
> 
>  > Someone please tell me: What is the proper response when
>  > you are kicked in the balls by a three-foot dwarf?
> 
> Walk away ! Let it drop etc. etc. etc.
> 
> PS. Since you neither confirm nor deny being the same
> Russ that perpetually (since you allow yourself to use
> unsupported "facts", I will use perpetually instead of
> last year) brings up the absolute cure all solution
> to Ada's woes as "+=", I will refer you to the other
> Russ's 7 points which are guaranteed to save Ada from
> joining the dinosaurs.
> 
> Visit :
> 
> "http://russp.org" (note the witty and clever intro cross
> out of rantings)

I didn't want to shamelessly plug my website, but if you insist, I
certainly don't mind the extra traffic.

> Select "Features" and page down to the bottom and
> see "A Cleaner Syntax for Ada Programming".

While you're at it, take a look at "Ignorance About Nuclear Power is
Killing Us" (http://RussP.org/nucpower.htm).

Re: += in ada

[Ross Higson]

Russ wrote:
> 
> Someone please tell me: What is the proper response when you are
> kicked in the balls by a three-foot dwarf?

If a three foot dwarf can kick you in the balls, you must be very short 
indeed!

Re: += in ada

[Jerry Petrey]

Ross Higson wrote:

> Russ wrote:
> >
> > Someone please tell me: What is the proper response when you are
> > kicked in the balls by a three-foot dwarf?
>
> If a three foot dwarf can kick you in the balls, you must be very short
> indeed!

Or have very big balls :-)

Re: += in ada

[Preben Randhol]

On 2003-10-21, Russ <18k11tm001@sneakemail.com> wrote:
> Someone please tell me: What is the proper response when you are
> kicked in the balls by a three-foot dwarf?

I don't know. You tell us as you have been doing plenty of kicking here.
Your height I wouldn't know though.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: += in ada

[Martin Dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
> But if I want efficient matric addition in C++ there is rarely any
> reason to use anything other than
>
>   A += B; // lots of room for a comment here, but none needed!

Well, for efficient matrix operations with in-fix notation, check out
AI-296 and AI-318 , which should sort this out for most cases.

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00318.TXT


> Every little thing that can help improve Ada's popularity without
> damaging its effectiveness is critical now. If the Ada 200x design
> team gets too conservative, Ada will almost certainly work its way out
> of the picture.

Well, for 200Y some serious 'C++/Java'-style improvements are on the
cards (though not yet approved), e.g.

'interfaces' a la Java, and
Object.Method notation like C++/Java/etc.

So, the ARG _have_ been listening and 'borrrowing' ideas from other
languages. These 2 proposals have _really_ big advantages but even
then there is a long and hard discussion about how to define them
consistently within Ada.

I'm reminded of a quote from Bertrand Meyer
  "Eiffel borrows quite heavily from some earlier programming
   languages and I am sure that if we had found a good programming
   construct in C we would have used it as well.".


There just isn't enough time to get everyones favourite 'hobby horse' in
the new standard - you could always push for this in Ada1Z! :-)


> Take a look some time at comp.lang.c, comp.lang.c++, comp.lang.java.*,
> comp.lang.perl, and comp.lang.python. You might just find that each of
> them gets more posts in a day than comp.lang.ada gets in a month. Is
> that *because* they each have "+="? I don't know, but you cannot deny
> the correlation between "+=" and popularity. (Of course, they all use
> "=" rather than ":=" for assignment, which may also be a huge factor,
> but that's another story.)

I've stopped lurking in comp.lang.c++ as the quality of the posts was,
soooo amazing poor. And I think it says a lot about the language that
there are _so_many_ questions, and repeated questions from beginners.


> > don't care. I'd just suggest dropping the lobbying for it because it
> > isn't going to happen.
>
> I've already wasted more than enough time on this little endeavor, so
> I may just take your suggestion.

I think you're way too late to influence Ada0Y but come back with
an AI after Ada05 (or what ever) is approved and when the ARG
are starting to look at the next revision...

...but be prepared! Have a look through the AI's (and AC's) that
have been raised for this standardization and check on the level of
debate that is required to persuade anyone of this merits of any
particular case.

Here's the link for the AI:
http://www.ada-auth.org/AI-SUMMARY.HTML

And for all discussions:
http://www.ada-auth.org/ais.html

Re: += in ada

[Hyman Rosen]

Martin Dowie wrote:
> I've stopped lurking in comp.lang.c++ as the quality of the posts was,
> soooo amazing poor. And I think it says a lot about the language that
> there are _so_many_ questions, and repeated questions from beginners.

Don't you wish Ada had as many beginners?

Re: += in ada

[Martin Dowie]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1066669506.172026@master.nyc.kbcfp.com...
> Martin Dowie wrote:
> > I've stopped lurking in comp.lang.c++ as the quality of the posts was,
> > soooo amazing poor. And I think it says a lot about the language that
> > there are _so_many_ questions, and repeated questions from beginners.
>
> Don't you wish Ada had as many beginners?

:-)

Re: += in ada

[Hyman Rosen]

You're right, of course, about the public C++ groups.
The moderated ones, comp.lang.c++.moderated and comp.std.c++,
are fine, though. We get into exactly the same dumb and long
arguments about picayune language features that c.l.a does.

Re: += in ada

[Wes Groleau]

Martin Dowie wrote:
> Well, for 200Y some serious 'C++/Java'-style improvements are on the
> cards (though not yet approved), e.g.
> 
> 'interfaces' a la Java, and
> Object.Method notation like C++/Java/etc.

Interfaces I think there may be some value to.

But Object.Method ?

I can understand (though I disagree with) someone
who believes that

   X += 1

is easier to read than

   Inc(X)

But someone who is not capable of learning and using
both is not capable of being a competent programmer.

The same applies to Method(Object) vs. Object.Method

Please explain to me WHY someone thinks this is a
"serious improvement" ?

-- 
Wes Groleau
Can we afford to be relevant?
http://www.cetesol.org/stevick.html

Re: += in ada

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]


"Wes Groleau" <groleau@freeshell.org> wrote in message
news:e4WdneVLhtPUGQmiU-KYgw@gbronline.com...
>
> Interfaces I think there may be some value to.

*** So do I, but not at all costs, in some situations I found iterfaces
sacrificed some native capabilities of OOP no matter the language.  Besides
if you use polymorphism right combined with good naming conventions, there's
no need for interfaces ;-).  but on very big scale projects maybe an
inteface can be good to force a minimal proper implementation of an related
object.
>
> But Object.Method ?
>
*** I agree here, not sure what the point is to object methods.  That would
be like trying to sell me an orange and what I want is an apple but the
selling argument would be that an orange is a fruit and therefore can take
the place of my apple ;-).

> I can understand (though I disagree with) someone
> who believes that
>
>    X += 1
>
> is easier to read than
>
>    Inc(X)
>
> But someone who is not capable of learning and using
> both is not capable of being a competent programmer.
>
*** Indeed, programming is a context related exercise.  Hence if I'm in Ada,
Pascal, I'll use Inc(X) and smile, if I "have to" use C or C++ I'll use +=
and smile (though a bit less ;-).  But I also fail to see why one should be
used over the other. += certainly didn't make or break C or C++ and he or
she (I'm an equal oppurtunity flamer ;-) who thinks otherwise needs to do a
detailed history review of C and C++ ;-).

> The same applies to Method(Object) vs. Object.Method
>
> Please explain to me WHY someone thinks this is a
> "serious improvement" ?
>
*** My theoretical, theoretical mind you, is that it's the first
implementation they learned, and wouldn't want to change the way they
understood it ;-).

> -- 
> Wes Groleau
> Can we afford to be relevant?
> http://www.cetesol.org/stevick.html
>

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com




-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: += in ada

[Hyman Rosen]

Wes Groleau wrote:
> The same applies to Method(Object) vs. Object.Method
> Please explain to me WHY someone thinks this is a
> "serious improvement" ?

I don't actually know if this applies to the proposed
implementation in Ada, but I would imagine that the
Object.Method syntax uses only the Object as the thing
upon which to dispatch. I believe as things stand now
in Ada, if you write a method which you would like to
be dispatching, and it takes more than one parameter of
the object type, then all the arguments must be of the
same dynamic type.

Re: += in ada

[Martin Dowie]

Wes Groleau <groleau@freeshell.org> wrote in message news:<e4WdneVLhtPUGQmiU-KYgw@gbronline.com>...
> But Object.Method ?

Yes, it would reduce the need to "use" clauses, as the context can
be determined from the object. A nice IDE could then produce a pop-up,
list menu of available methods that can be called (similar to what
Rational Apex or AdaGIDE do).

It is relatively simple for compilers to implement too (~130 sloc
for GNAT apparently).

Here a link to the current proposal (by Tucker himself! :)
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00252.TXT?rev=1.7

Re: += in ada

[Marius Amado Alves]

On Tue, 2003-10-21 at 00:57, Wes Groleau wrote:
> Martin Dowie wrote:
> > Well, for 200Y some serious 'C++/Java'-style improvements are on the
> > cards (though not yet approved), e.g.
> > 
> > 'interfaces' a la Java, and
> > Object.Method notation like C++/Java/etc.
> 
> Interfaces I think there may be some value to.

No. They're useless. Ada 95 has several idioms to accomplish what Java
does with interfaces. (This has been shown in a recent Ada-Europe
conference by J.-P. Rosen. I think he won the best paper.)

> But Object.Method ?

Ditto.

Ditto for += etc.

I really hate these proposals. Ada is already a big language. Stuff like
this only makes it bigger--to no advantage whatsoever.

Libraries is the way. I am 100% with the CAL idea.

Re: += in ada

[Marin David Condic]

Libraries are a very important thing - but maybe not the only thing. 
Thanks for the vote of confidence though. ;-)

I think some advantage could come from trying to identify some market 
segment and bending over backwards to give them what they want. 
Something a little less vague than "High Reliability - Long Lived 
Systems" - although that's not a bad start. Something along the line of 
"Cable TV" or "Cellular Phones" or "GUI Based Business PC Apps". 
Libraries that catered to some problem domain - along with whatever 
other support tools or language adaptations might fit with that - could 
go a long way in establishing a larger base for Ada.

We can pretty much scratch "Embedded Systems" off the list given that 
"Other" ranks higher than "Ada" in surveys of computer languages used 
for embedded systems. I think they're too entirely unimpressed with Ada 
(to put it poklitely) to come back any time soon. If we wanted to win 
that crowd, the way to do it is get the language bigger in some other 
sector such that there is more growth of support structures needed to 
make it attractive for an embedded system.

MDC


Marius Amado Alves wrote:
> 
> Libraries is the way. I am 100% with the CAL idea.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Marius Amado Alves]

On Tue, 2003-10-21 at 13:00, Marin David Condic wrote:
> Something a little less vague than "High Reliability...

Give me High Reliability every time. In two days my OpenOffice crashed
twice, making me loose work. I say "Ada on the Desktop: safe power
tools." I think there is a universal market for safe applications, and
thus an indirect market for Ada. "100% Ada, 0 bugs."

Re: += in ada

[Robert I. Eachus]

Marius Amado Alves wrote: "100% Ada, 0 bugs."

If you don't intend to copyright that, look for it to show up as my next 
.sig.  No smilely.  That is the campaign that Ada needs.  We could argue 
details like "0 bugs" vs. "no bugs" vs. "zero bugs."  but that is a 
minor detail.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F95475C.2010004@comcast.net...
> Marius Amado Alves wrote: "100% Ada, 0 bugs."
>
> If you don't intend to copyright that, look for it to show up as my next
> .sig.  No smilely.  That is the campaign that Ada needs.  We could argue
> details like "0 bugs" vs. "no bugs" vs. "zero bugs."  but that is a
> minor detail.
>
> -- 
>                                                      Robert I. Eachus

*** I'll be looking, that's an eye catcher alright :-).
-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: += in ada

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

I would add a small symbol however :-).

100% Ada = 0% Bugs  ?? ;-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F95475C.2010004@comcast.net...
> Marius Amado Alves wrote: "100% Ada, 0 bugs."
>
> If you don't intend to copyright that, look for it to show up as my next
> .sig.  No smilely.  That is the campaign that Ada needs.  We could argue
> details like "0 bugs" vs. "no bugs" vs. "zero bugs."  but that is a
> minor detail.
>
> -- 
>                                                      Robert I. Eachus
>
> "Quality is the Buddha. Quality is scientific reality. Quality is the
> goal of Art. It remains to work these concepts into a practical,
> down-to-earth context, and for this there is nothing more practical or
> down-to-earth than what I have been talking about all along...the repair
> of an old motorcycle."  -- from Zen and the Art of Motorcycle
> Maintenance by Robert Pirsig
>

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Robert I. Eachus wrote:

>Marius Amado Alves wrote: "100% Ada, 0 bugs."
>
>If you don't intend to copyright that, look for it to show up as my next 
>.sig.  No smilely.  That is the campaign that Ada needs.  [...]

Yes, sounds pretty perfect for a marketing campaign. Even a little,
but important detail is not missing: It is simply a lie.

Consider using "0%" instead. This wouldn't be a lie, it would be just
a good approximation. :)


Vinzent.

Re: += in ada

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

Great minds think alike no Vinzent ? ;-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Vinzent 'Gadget' Hoefler" <ada.rocks@jlfencey.com> wrote in message
news:bn3i63$sn9en$1@ID-175126.news.uni-berlin.de...
Robert I. Eachus wrote:

>Marius Amado Alves wrote: "100% Ada, 0 bugs."
>
>If you don't intend to copyright that, look for it to show up as my next
>.sig.  No smilely.  That is the campaign that Ada needs.  [...]

Yes, sounds pretty perfect for a marketing campaign. Even a little,
but important detail is not missing: It is simply a lie.

Consider using "0%" instead. This wouldn't be a lie, it would be just
a good approximation. :)


Vinzent.

Re: += in ada

[(see below)]

On 21/10/03 16:07, in article bn3i63$sn9en$1@ID-175126.news.uni-berlin.de,
"Vinzent 'Gadget' Hoefler" <ada.rocks@jlfencey.com> wrote:

>> If you don't intend to copyright that, look for it to show up as my next
>> .sig.  No smilely.  That is the campaign that Ada needs.  [...]
> 
> Yes, sounds pretty perfect for a marketing campaign. Even a little,
> but important detail is not missing: It is simply a lie.
> 
> Consider using "0%" instead. This wouldn't be a lie, it would be just
> a good approximation. :)

"100% Ada => no bugs" ??
----------^^
That makes it an "aspiration", as politicians say.
8-)

-- 
Bill

Re: += in ada

[Dmitry A. Kazakov]

On Tue, 21 Oct 2003 14:50:15 GMT, "Robert I. Eachus"
<rieachus@comcast.net> wrote:

>Marius Amado Alves wrote: "100% Ada, 0 bugs."
>
>If you don't intend to copyright that, look for it to show up as my next 
>.sig.  No smilely.  That is the campaign that Ada needs.  We could argue 
>details like "0 bugs" vs. "no bugs" vs. "zero bugs."  but that is a 
>minor detail.

"Zero bugs" are probably ones like:

if (x_ptr = 0) return;
*x_ptr++;

(:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: += in ada

[Marius Amado Alves]

On Tue, 2003-10-21 at 14:50, Robert I. Eachus wrote:
> Marius Amado Alves wrote: "100% Ada, 0 bugs."
> 
> If you don't intend to copyright that, look for it to show up as my next 
> .sig.

It's copyrighted by default like everything you write, but I hereby
grant permission to use in email signatures and documents promoting Ada
and the CAL. /* Eventually I'll give the motto to CAL or some other
appropriate organization. Anyway I promise I wont charge royalties until
the organization gets stinky rich. */

Re: += in ada

[Preben Randhol]

On 2003-10-21, Robert I. Eachus <rieachus@comcast.net> wrote:
> Marius Amado Alves wrote: "100% Ada, 0 bugs."
>
> If you don't intend to copyright that, look for it to show up as my next 
> .sig.  No smilely.  That is the campaign that Ada needs.  We could argue 
> details like "0 bugs" vs. "no bugs" vs. "zero bugs."  but that is a 
> minor detail.

*Alarm bells* We will have a lot of discussions with C / C++ zealiots
who will think Ada will prevent any bug from happening also logical
bugs. On the other hand one cannot write: "100% Ada, fewer bugs" and
hope to raise any eyebrows either :-)

*rolling up sleeves* ;-)

Preben
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Preben Randhol wrote:

>*Alarm bells* We will have a lot of discussions with C / C++ zealiots
>who will think Ada will prevent any bug from happening also logical
>bugs.

Well, that doesn't really matter. The C zealots - at least the ones I
know - claim one can write code with zero bugs in C when one is
careful enough.

Well, one way or another, they're right, too. :->


Vinzent.

Re: += in ada

[Robert I. Eachus]

Vinzent 'Gadget' Hoefler wrote:

> Well, that doesn't really matter. The C zealots - at least the ones I
> know - claim one can write code with zero bugs in C when one is
> careful enough.
> 
> Well, one way or another, they're right, too. :->

Someday, I'll meet a C programmer that good. But I am not holding my breath.

A long time ago when I was at Stratus, we looked at the cost of 
"bug-free" code.  The first conclusion was that it was possible to 
improve code with less than one bug per 10,000 lines or so to the point 
where there were no known bugs and there was an expectation that there 
were no unknown bugs.  Code with about one known bug per 1000 lines was 
problematical.  There was no easy was to determine whether there was a 
way to remove all the bugs, including latent bugs, or if you were better 
starting over.

Stratus had a lot of PL/I code that was significantly better than the 
one bug per thousand lines criteria, and some that was worse, so we 
tended to use that number when deciding whether to upgrade for the next 
OS version or rewrite.  Most of the C code we had was closer to one 
known bug per 100 lines.  Fortunately most of it was in small drivers.
-- 
                                             Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Robert I. Eachus wrote:

>Vinzent 'Gadget' Hoefler wrote:
>
>> Well, that doesn't really matter. The C zealots - at least the ones I
>> know - claim one can write code with zero bugs in C when one is
>> careful enough.
>> 
>> Well, one way or another, they're right, too. :->
>
>Someday, I'll meet a C programmer that good.

Obviously you missed the part of the sentence I did not write. You
wouldn't meet him because he is still trying to be careful. :)

>OS version or rewrite.  Most of the C code we had was closer to one 
>known bug per 100 lines.  Fortunately most of it was in small drivers.

That still makes 10 bugs per application or so... ;-)


Vinzent.

Re: += in ada

[Robert I. Eachus]

Vinzent 'Gadget' Hoefler wrote:

>>OS version or rewrite.  Most of the C code we had was closer to one 
>>known bug per 100 lines.  Fortunately most of it was in small drivers.
>  
> That still makes 10 bugs per application or so... ;-)

Correct.  At least half of them were potential buffer overflow errors. 
In theory you can fix those in the C code, but in practice checking the 
length of C strings in the C code would cause other (timing) problems. 
So most of them were documented and the checks were done in the OS (in 
PL/I) where possible.  In other cases, such as disk block sizes, we had 
control of block sizes for disks attached locally, but an NFS attached 
disk could cause problems, or if someone tried to attach a disk with a 
non-OS set block size...

There were at least three cases I know of at Stratus where a low-level 
driver was rewritten in Z-80 or whatever assembler as the only good way 
of avoiding a particular buffer overflow problem or an underrun problem. 
  (If you don't transmit all of a C string or other variable C array 
before time runs out, bad things happen.)

-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Hyman Rosen]

Marius Amado Alves wrote:
> No. They're useless. Ada 95 has several idioms to accomplish what Java
> does with interfaces.

The one thing you can do with interfaces that you cannot do in other
ways is cross-cast between them, without having to know or mention a
common ancestor or containing type.

Re: += in ada

[sk]

Martin Dowie <martin.dowie@btopenworld.com>:
 > Here's the link for the AI:
 > http://www.ada-auth.org/AI-SUMMARY.HTML

I have been meaning to ask for a long time, but ...

... anyway, how does one actually see an AI ?

Everytime someone links to the AI's I always
get stuck at a CVS log page offering "diff"'s
and cannot get any further.

Do I need to enable active controls on my browser
or something (Javascript etc) ?


-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[Simon Wright]

sk <noname@myob.com> writes:

> Everytime someone links to the AI's I always
> get stuck at a CVS log page offering "diff"'s
> and cannot get any further.
> 
> Do I need to enable active controls on my browser
> or something (Javascript etc) ?

If you go to eg
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00002.TXT you will
see the top entry is for rev 1.6; click on the 1.6 and there you are
..

Re: += in ada

[sk]

simon@pushface.org:
 > ...

I embarassingly overlooked the obvious :-)

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: += in ada

[chris]

Russ wrote:

> Oh, isn't that wonderful. Pascal, Fortran, and Ada. Did you contribute
> your "wisdom" to the demise of Pascal and Fortran too? 

Pascal is in decline?  Someone tell Borland quick!  ;)

Re: += in ada

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0310181737.5e370815@posting.google.com...

> Oh, I see. So efficiency is no longer an issue. Well, excuse me, but I
> think we'd be better off leaving that judgment to each application
> developer. Controlling a building temperature is one thing, but
> delivering a cruise missile to Saddam Hussein's front door is quite
> another.

*** I'm not one to dispute usually.  But this += thread is getting pathetic
from the likes of you.  Oh and By the way, Pascal may not have +=, it has
Inc and Dec who's resulting compiled code is as efficient as C's +=.  Don't
believe me? Do some benchmarks.
>
> Do you have any idea whatsoever how much computation is potentially
> involved in computing optimal conflict-free trajectories for thousands
> of airplanes? Here's a suggestion: if you don't know WTF you are
> talking about, STFU.
>
*** Hmmm you don't know who you're talking to do you?  Marin can probably
run circles around you while computing the circle's trajectory around you?
No he didn't invent them, but he sure can use them :-).   However, I find
quite primitive a mind one that resolves to insults and STFU's instead of
bringing real arguments about real issues that really need resolving.  If
YOU run out of things to say, just say so, what's this attitude about not
admitting that you're out of arguments?

>
> Oh, isn't that wonderful. Pascal, Fortran, and Ada. Did you contribute
> your "wisdom" to the demise of Pascal and Fortran too? I guess you're
> going for the trifecta with Ada, eh? Ever heard of "three strikes and
> you're out"?

*** Like chris said I should email Borland and let them know that their
technology of the future has been dead for 5 years?  Now why do you think
that Borland, among others have a C++ and a Pascal Compiler, they dont both
have the += operator set and yet both are popular enough?  Do you bother
looking at market shares before saying foolish things?

>
>
> Oh, so let's neglect the little things and focus on the big things.
> Here's a little piece of wisdom for you: if you don't bother getting
> the little things right, you probably won't get the big things right
> either.

*** well most scientist wouldn't agree with you since they all try to grasp
the most complicated aspect of a subject and often fail to grasp the obvious
;-).  To me, I don't care too much about the += issue.  Like Marin said
there's ways around it which means that it's not a "critical" issue.

Here's my critical issue, why are people like you wasting people's time.
People that actually aim to make Ada better than it already is right now
(which is already much better than any dialect of C or C++).  Ada isn't a
library for C++ Russ it has no standard definitions that tells Ada compilers
to abide by C/C++ standards. So C/C++ have the +=, good for them,
ObjectPascal doesn't (but there's ways around it). Ada Doesn't but there's
ways around it.  As far as I'm concerned, that's the end of this discussion.
+- os a question of Taste, not a question of performance as it can be
achieved otherwise.


-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: += in ada

[Robert I. Eachus]

Russ wrote:

> Oh, I see. So efficiency is no longer an issue. Well, excuse me, but I
> think we'd be better off leaving that judgment to each application
> developer. Controlling a building temperature is one thing, but
> delivering a cruise missile to Saddam Hussein's front door is quite
> another.

No.  Efficiency on the level you are talking about, in Ada, is something 
we delegate to the compiler.  We want software engineers, safety 
engineers, and security experts to be able to worry about much trickier 
stuff.  Do you want your security experts searching code for potential 
buffer overruns, or looking for covert timing channels?  In Ada, we 
prefer to leave the stuff that machines can do best to machines.

> Do you have any idea whatsoever how much computation is potentially
> involved in computing optimal conflict-free trajectories for thousands
> of airplanes? Here's a suggestion: if you don't know WTF you are
> talking about, STFU.

If you would like to get serious on this subject, ask me about an Ada 
implementation of the assignment problem that used sparse matrices, and 
a very fast algorithm.  (The air traffic control problem is just a huge 
assignment problem.  You want to assign aircraft to airspace most 
efficiently, subject to the very important constraint that there is at 
most one airplane in any available airspace. ;-)  As for whether or not 
that work is applicable to air traffic control, it was done as part of 
the RSIP upgrade of AWACS.  A major potential problem was that 
increasing the radar sensitivity would be useless without the ability to 
effectively track and manage all that traffic.

That is the level at which you should be worrying about efficiency, not 
the micro efficency of allocating temporaries.  And besides, as I said, 
in modern CPUs, anything you learned about that in school is totally 
obsolete.  That probably includes all classes in Assembler being taught 
right now.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Hyman Rosen]

Robert I. Eachus wrote:
> No.  Efficiency on the level you are talking about, in Ada, is something 
> we delegate to the compiler.  We want software engineers, safety 
> engineers, and security experts to be able to worry about much trickier 
> stuff.  Do you want your security experts searching code for potential 
> buffer overruns, or looking for covert timing channels?  In Ada, we 
> prefer to leave the stuff that machines can do best to machines.

This statement means that we get to talk about the Ariane 5 again.
If you recall, this involved careful case-by-case analysis of every
aritmetic statement in a module to determine which ones could have
their range checks disabled, in order to free up a few more machine
cycles. No "delegation to the compiler" there.

We can also bring up protected types. Apparently the real-time
community felt that leaving efficiency to the compiler and using
rendezvous was not acceptable.

Re: += in ada

[Robert I. Eachus]

Hyman Rosen wrote:

> This statement means that we get to talk about the Ariane 5 again.
> If you recall, this involved careful case-by-case analysis of every
> aritmetic statement in a module to determine which ones could have
> their range checks disabled, in order to free up a few more machine
> cycles. No "delegation to the compiler" there.

No, but unless you missed the last discussion of Ariane 5, you would 
know that the problem with Ariane 5 was not spending enough time on 
things other than counting machine cycles.  And the machine cycle 
counting, which are never wrong in a hard-real-time system was done 
right in the Ariane 4 context where it occurred.  Ariene 4 is/was a 
great success and is still being used today.  There have been several 
Ariane 5 failures since the first, and each of them has eventually been 
traced back to the Ariane 5 development team skimping on requirements 
analysis at the highest levels.

> We can also bring up protected types. Apparently the real-time
> community felt that leaving efficiency to the compiler and using
> rendezvous was not acceptable.

If you don't understand protected types, I'm not going to try to explain 
it all here.  But to vastly shorten the discussion, some Ada (83) 
compilers supported special optimizations for what were called things 
like monitor tasks (Verdix).  Basically these were tasks with a special 
structure that allowed the compiler to produce more efficient code.  All 
of the code ran in the stacks of calling tasks, none in the monitor 
task, so it didn't need some resources, including a task control block, 
or any visibility to the scheduler.  Protected types are basically a 
cleaner notation for what many programs did with monitor tasks.

I once said that tasks in Ada were like rabbits, once you had two or 
more, if you didn't kept them segregated, you started finding baby tasks 
everywhere.  Protected objects and protected types make this distinction 
clean.  There are tasks which contain threads of control, and protected 
objects that are used for syncronization and communication between them. 
  If you find the name funny, maybe now you understand why it is so 
perfect. ;-)


-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Hyman Rosen]

Robert I. Eachus wrote:
> No, but unless you missed the last discussion of Ariane 5, you would 
> know that the problem with Ariane 5

I was simply pointing out that here was a real-life Ada software
project that devoted plenty of energy to counting cycles, rather
than leaving it to the compiler.

Re: += in ada

[Robert I. Eachus]

Hyman Rosen wrote:

> I was simply pointing out that here was a real-life Ada software
> project that devoted plenty of energy to counting cycles, rather
> than leaving it to the compiler.

And my point was that they didn't.  They reused the code from the Ariane 
4 without change, assuming that way they didn't have to repeat the cycle 
counting.  After all the same code on the same hardware would produce 
exactly the same results.

Of course, the problem was that the guidance hardware was identical, but 
the trajectory, inertial moments for the stack, and maximum safe engine 
deflection were not.  That made all of their software reuse assumptions 
invalid.  The next two Ariane 5 failures were hardware failures, but the 
root cause was identical.  You can't change part of the system, and then 
assume that the requirements don't change elsewhere.  (The most recent 
failure flight 157 in December 2002 dumped two satellites in the 
Atlantic Ocean.  Preliminary data indicated a cooling problem in the 
uprated Vulcan 2 engines, but a final report has yet to be published.)

-- 
                                          Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Hyman Rosen]

Robert I. Eachus wrote:
> They reused the code from the Ariane 4 without change,

Then the Ariane 4 people counted the cycles.
You were claiming that Ada people believe that this sort
of micro-efficiency is in the domain of the compiler, and
I am pointing you at a prominent real-life project where
this was not the case.

Re: += in ada

[Marin David Condic]

Sometimes it is neccessary - either you do a hand optimization or you 
drop the project. (Been there. Done that. Same processor as the Ariane 
5, BTW)

But the point ought to be that in the overwhelming bulk of applications, 
this is not necessary. Most of the time, what the compiler does is 
*better* and one should leave it alone. Once in a great while, you are 
so bound by time, you *must* turn off all checks, struggle for every 
optimization, etc. This is just extremely rare and should not be 
undertaken lightly.

Also, it was never clear to me that leaving in the checks would have 
saved the Ariane 5. After all, the software did exactly what it was 
designed to do. It detected a fault, presumed it was a hardware failure 
and shut down the channel. Had the overflow been trapped by an exception 
handler instead of the hardware interrupt, the decision would have been 
the same. The FDA was correct for the Ariane 4. Just that in the Ariane 
5, it wasn't a "Failure" so the "Detection" and "Accommodation" was the 
wrong thing.

MDC



Hyman Rosen wrote:
> 
> Then the Ariane 4 people counted the cycles.
> You were claiming that Ada people believe that this sort
> of micro-efficiency is in the domain of the compiler, and
> I am pointing you at a prominent real-life project where
> this was not the case.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: += in ada

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> I was simply pointing out that here was a real-life Ada software
> project that devoted plenty of energy to counting cycles, rather
> than leaving it to the compiler.

Do you mean that they inserted hand-written machine code in some places? 
If not then they still were "leaving it to compiler", I think.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: += in ada

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> Do you mean that they inserted hand-written machine code in some places? 
> If not then they still were "leaving it to compiler", I think.

They went through several places where arithmetic overflow could
conceivably happen, deciding on a case-by-case basis whether the
external constraints on the data would justify omitting the check.
They did this in order to free up processor cycles to get the duty
cycle velow a prescribed maximum. You may look at that through Ada-
colored glasses if you like and call it still leaving it to the
compiler.

Re: += in ada

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> > Do you mean that they inserted hand-written machine code in some places? 
> > If not then they still were "leaving it to compiler", I think.
>
> They went through several places where arithmetic overflow could
> conceivably happen, deciding on a case-by-case basis whether the
> external constraints on the data would justify omitting the check.
> They did this in order to free up processor cycles to get the duty
> cycle velow a prescribed maximum.

All right, they measured timings, and perhaps they read compiler output and
really counted cycles - so what? They still trusted compiler for its work,
including optimization, and didn't try to replace it in critical places by
hand-written machine code. They surely used language features for influencing
compiler output - so what? Those language features was included in the language
exactly for that purpose.

> You may look at that through Ada-
> colored glasses if you like and call it still leaving it to the
> compiler.

Particular language, Ada in the case, is completely irrelevant here. I would
say the same for any language, including C++ (and even Java -;) in similar
circumstances. And I'm so sure of that because I know too well (from my own
experience) what is true hand-made optimization at the machine code level.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: += in ada

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> Particular language, Ada in the case, is completely irrelevant here.

Robert Eachus said
     "No.  Efficiency on the level you are talking about, in Ada,
     is something we delegate to the compiler."

I was merely pointing to a very prominent example demonstrating
that his statement is not (universally) correct.

Re: += in ada

[Dmytry Lavrov]

Russ,

How many times you're mistyped :+ as := ? (because + is on same key as
=)
And,if i'm writing
c:=a+b;
(a,b,c is not a booleans)
and making mistake
c:=a=b;
i will see compiler error.
But in
a:+b;
and a:=b;
it's compilable typo.
I think(because had very bad typos) that compilable typo is a really
worstest bug you can have.
It's spending days thinking what's wrong!(especially if almost always
a=0,and after some improvement,a<>0).

>Oh, I see. So efficiency is no longer an issue. Well, excuse me, but
I
>think we'd be better off leaving that judgment to each application
>developer. Controlling a building temperature is one thing, but
>delivering a cruise missile to Saddam Hussein's front door is quite
>another.

About speed of a:=b+c;
Some CPU's simply can't "add to ram"  (don't have such instruction),
for many other CPU's,it's NOT faster to do
mov eax,b
add a,eax
than
mov eax,a
add eax,b
mov a,eax
because in both examples,processor have to read a and b into
registers,add 'em,and then put result into ram.It's basics about how
cpu works.Ram simply can't "add value from cpu".If course,first
example is smaller,and have lesser number of instructions to
execute,but it does not make so big difference,and some x86 CPUs does
last example FASTER than first (really,you should know it if you're
worry so much about speed).

And about more complex datatypes:
it's better to write procedure than to overload an operator,especially
in safety critical system.
If you're REALLY care about speed,you should manually  simplify
expressions with,for example,vectors,for each component of
vector(huh,do yo ever think about doing it for matrices(big
enought,say,>4x4)? It's like nightmare).
And especially about matrices ,vectors,and ":*"
1:math operation need temp itself.
2: a*b<>b*a, so we should have different operators for 
a:=a*b;
and
a:=b*a;

Dmytry Lavrov.
http://dmytrylavrov.narod.ru/voxfoge.htm

Re: += in ada

[Hyman Rosen]

Robert I. Eachus wrote:
> Which makes Ada better for most common CPUs today, right?

No, you are forgetting that these operators are intended to
be defined for all sorts of types, where the temporaries may
be very large data structures, such as matrices.

Anyway, I'm not an Ada programmer, so I don't really care if
Ada has these operators or not. If I had to do stuff like this
in Ada, I would just write the appropriate procedures and be
done with it. In C++, I use these operators all the time. I
just did a quick search through the source code we've added to
out trading system and counted around 500 uses of augmented
assignment operators (+=, -=, *=, /=), and yes, we actually do
have a few cases of /=. We also have a few of those complicated
left-hand sides that people talk about; here's one:

     (*fxMap)[exposure.secCurr.id().get_key()] += exposure.secExp;

Re: += in ada

[Lutz Donnerhacke]

* Hyman Rosen wrote:
> No, you are forgetting that these operators are intended to
> be defined for all sorts of types, where the temporaries may
> be very large data structures, such as matrices.

Ada provides 'in out' parameters of procedures for that purpose.

> Anyway, I'm not an Ada programmer, so I don't really care if
> Ada has these operators or not. If I had to do stuff like this
> in Ada, I would just write the appropriate procedures and be
> done with it.

Please simply do this:
 procedure Mult_To_Left(target : in out Matrix; factor : in Matrix);

> In C++, I use these operators all the time.

You should stick to normal programming. It's much more funny than dealing
with one syntatic element all the time.

> I just did a quick search through the source code we've added to out
> trading system and counted around 500 uses of augmented assignment
> operators (+=, -=, *=, /=), and yes, we actually do have a few cases of
> /=. We also have a few of those complicated left-hand sides that people
> talk about; here's one:
> 
>      (*fxMap)[exposure.secCurr.id().get_key()] += exposure.secExp;

declare
   fxExp : Fx_Type renames fxMap(exposure.secCurr.id.get_key);
begin
   fxExp := fxExp + exposure.secExp;
end;

So what's your point?

Ah! Multiple lines:
  procedure Add (to: in out Fx_Type; term : in Fx_Type) is
  begin
     to := to + term;
  end add;

[...]
  Add(to => fxMap(exposure.secCurr.id.get_key), term => exposure.secExp);
  Add(fxMap(exposure.secCurr.id.get_key), exposure.secExp);
  
Have fun.

Re: += in ada

[Hyman Rosen]

Lutz Donnerhacke wrote:
> Please simply do this:
>  procedure Mult_To_Left(target : in out Matrix; factor : in Matrix);

Yes, that's what I said.

>>In C++, I use these operators all the time.
> 
> You should stick to normal programming. It's much more funny than dealing
> with one syntatic element all the time.

I don't understand this sentence at all. What do you mean?

> So what's your point?

I don't have a point, exactly. I was just pointing out that the
augmented assignment operators are used very frequently in normal
C++ code, and some of those uses involve those complicated left
side expressions. This is real production code, not a made-up
example. I think some people here believe that such an operator
is a rara avis that even if available would be rarely used.

 > declare
 >    fxExp : Fx_Type renames fxMap(exposure.secCurr.id.get_key);
 > begin
 >    fxExp := fxExp + exposure.secExp;
 > end;
 >
And now that you mention it, there's a considerable problem with
the renames idiom; you must repeat the type of the thing you're
renaming.

> Ah! Multiple lines:
>   procedure Add (to: in out Fx_Type; term : in Fx_Type) is
>   begin
>      to := to + term;
>   end add;
> 
> [...]
>   Add(to => fxMap(exposure.secCurr.id.get_key), term => exposure.secExp);
>   Add(fxMap(exposure.secCurr.id.get_key), exposure.secExp);
>   
> Have fun.

I would hope that you at least use a generic instantiation instead of
littering your code all over the place with little bird droppings.

Re: += in ada

[Lutz Donnerhacke]

* Hyman Rosen wrote:
> Lutz Donnerhacke wrote:
>> Please simply do this:
>>  procedure Mult_To_Left(target : in out Matrix; factor : in Matrix);
>
> Yes, that's what I said.

Fine. So there is no need for augmented assignments. Right?

>>>In C++, I use these operators all the time.
>>
>> You should stick to normal programming. It's much more funny than dealing
>> with one syntatic element all the time.
>
> I don't understand this sentence at all. What do you mean?

You should try to use other syntactic elements of C++, too.

> I don't have a point, exactly. I was just pointing out that the
> augmented assignment operators are used very frequently in normal
> C++ code, and some of those uses involve those complicated left
> side expressions. This is real production code, not a made-up
> example.

There are syntactic elements (like nested functions or returning
unconstraint types) which are used in Ada code very frequently.
Does this imply, that C++ should add this instantanously?

> I think some people here believe that such an operator
> is a rara avis that even if available would be rarely used.

Other people think different.

> > declare
> >    fxExp : Fx_Type renames fxMap(exposure.secCurr.id.get_key);
> > begin
> >    fxExp := fxExp + exposure.secExp;
> > end;
>
> And now that you mention it, there's a considerable problem with
> the renames idiom; you must repeat the type of the thing you're
> renaming.

You know the type. So there is no problem with.

>> Ah! Multiple lines:
>>   procedure Add (to: in out Fx_Type; term : in Fx_Type) is
>>   begin
>>      to := to + term;
>>   end add;
>>
>> [...]
>>   Add(to => fxMap(exposure.secCurr.id.get_key), term => exposure.secExp);
>>   Add(fxMap(exposure.secCurr.id.get_key), exposure.secExp);
>>
>> Have fun.
>
> I would hope that you at least use a generic instantiation instead of
> littering your code all over the place with little bird droppings.

It's your code. I prefer renaming.

Re: += in ada

[Hyman Rosen]

Lutz Donnerhacke wrote:
> Fine. So there is no need for augmented assignments. Right?

That depends on your definition of "need".

As I said, in looking through the C++ code that we have written
to augment our trading system, I found about 500 uses of these
operators (none of them controlling for loops, despite what Robert
Eachus believes). The code involved spends its time adding things
up, multiplying by interest and exchange rates, dividing by 100
to convert percentages, et al. Did we "need" to use them? Certainly
not - we could have written all of them as A = A op B, and used
references for the rare complicated left-hand sides. Did we use
them since they are part of the language? Absolutely.

> There are syntactic elements (like nested functions or returning
> unconstraint types) which are used in Ada code very frequently.
> Does this imply, that C++ should add this instantanously?

Yes. But the C++ folks are as recalcitrant and
stubborn as the Ada ones :-)

>>And now that you mention it, there's a considerable problem with
>>the renames idiom; you must repeat the type of the thing you're
>>renaming.
> 
> You know the type. So there is no problem with.

How do you know the type? That is, if I write
     a.b.c.d.count := a.b.c.d.count + 1;
or even, using a pre-existing Inc,
     Inc(a.b.c.d.count);
I have no need to know the type of count. If I
use a renames, I have to go and look the type up.
If someone chooses to change the type, I have to
go and modify all the renames declarations.

>>I would hope that you at least use a generic instantiation instead of
>>littering your code all over the place with little bird droppings.
> 
> It's your code. I prefer renaming.

I meant, in order to generate the Add procedure.

Re: += in ada

[Preben Randhol]

On 2003-10-17, Hyman Rosen <hyrosen@mail.com> wrote:

> I think some people here believe that such an operator
> is a rara avis that even if available would be rarely used.

No, but 1) it would make Ada more sexy 2) the hassel of introducing it
is far greater than the benifit. 3) :+ :/ etc are less readable

People will use any thing available for the oddes things. Like using a
kitchen knife to screw in a screw :-)

Preben
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting is a bad thing!

Re: += in ada

[Preben Randhol]

On 2003-10-17, Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
> On 2003-10-17, Hyman Rosen <hyrosen@mail.com> wrote:
>
>> I think some people here believe that such an operator
>> is a rara avis that even if available would be rarely used.
>
> No, but 1) it would make Ada more sexy 2) the hassel of introducing it

Arg! It should be: No, but 1) it would *not* make Ada more sexy 

Preben
-- 
This is Ada95 land. On quiet nights you can hear C programmers debug.

Re: += in ada

[Wes Groleau]

Preben Randhol wrote:
> People will use any thing available for the oddes things. Like using a
> kitchen knife to screw in a screw :-)

Hey, the knife is right here, and the screwdriver
is all the way out in the garage.  Too far to go
for something as trivial as safety.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau/Wes

Re: += in ada

[Russ]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1066400123.238640@master.nyc.kbcfp.com>...
> Robert I. Eachus wrote:
> > Which makes Ada better for most common CPUs today, right?
> 
> No, you are forgetting that these operators are intended to
> be defined for all sorts of types, where the temporaries may
> be very large data structures, such as matrices.
> 
> Anyway, I'm not an Ada programmer, so I don't really care if
> Ada has these operators or not. If I had to do stuff like this
> in Ada, I would just write the appropriate procedures and be
> done with it. In C++, I use these operators all the time. I
> just did a quick search through the source code we've added to
> out trading system and counted around 500 uses of augmented
> assignment operators (+=, -=, *=, /=), and yes, we actually do
> have a few cases of /=. We also have a few of those complicated
> left-hand sides that people talk about; here's one:
> 
>      (*fxMap)[exposure.secCurr.id().get_key()] += exposure.secExp;

Thanks for that little dose of reality. I hope it wakes up a few
people around here (but I doubt it will).

I am curious about one thing. In your count of augmented assignment
operators, did you count loop incrementors? I would imagine most of
those are "++" rather than the basic four you listed, so I will assume
(unless you tell me otherwise) that you did not count them. Also,
approximately how many lines of code did you look in to find the 500
occurrences?

By the way, I have always considered the standard C/C++ "for"
construct to be awkward, and I think the Ada looping style is
preferable. Then again, many C++ programmers are probablly now using
STL iterators in lieu of the old-style "++" idioms.

Re: += in ada

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
: Hyman Rosen <hyrosen@mail.com> wrote in message news:<1066400123.238640@master.nyc.kbcfp.com>...
:>  In C++, I use these operators all the time. I
:> just did a quick search through the source code we've added to
:> out trading system and counted around 500 uses of augmented
:> assignment operators (+=, -=, *=, /=), and yes, we actually do
:> have a few cases of /=. We also have a few of those complicated
:> left-hand sides that people talk about; here's one:
:> 
:>      (*fxMap)[exposure.secCurr.id().get_key()] += exposure.secExp;
: 
: Thanks for that little dose of reality. I hope it wakes up a few
: people around here (but I doubt it will).

That makes 500 uses of mostly +=, -=, and *=, thanks for the data.
It doesn't say, though, how many lines of code were counted.
The examples provided (by Hyman and Lutz) do say something
about the uses.
As to reality, I am sure every one in this discussion has seen
+=. But I'd guess that they are still waiting for a detailed
argument about
- whether +:= can be done in Ada without introducing all sorts of
  little problems (as seems to be the case in Python, as someone
  has mentioned)
- whether implementing +:= is a hard problem. A detailed argument
  would, I guess, contain an estimate of the effort involved introducing
  +:= in Ada (not in some other language. SETL does have +:=, and SETL
  seems to have played a role during development of GNAT, and even 
  without that, I'd not assume that Ada compiler writers are out
  of touch with reality because they don't see the big win of
  +:= ?)

Have you answered the question about what should happen if during
assignment something goes wrong?  Do I have to make a backup
copy, then? Have I missed something?



Georg

Re: += in ada

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1066400123.238640@master.nyc.kbcfp.com...
>> done with it. In C++, I use these operators all the time. I
> just did a quick search through the source code we've added to
> out trading system and counted around 500 uses of augmented
> assignment operators (+=, -=, *=, /=),

How large is your trading system?  Would these 500 uses make up 10% of the
code, 1%, or 0.1%?

-CRM

Re: += in ada

[Hyman Rosen]

Chad R. Meiners wrote:
> How large is your trading system?  Would these 500 uses make up 10% of the
> code, 1%, or 0.1%?

It's not the whole system, for which we don't have source,
just the add-ons we ourselves have written. There's about
70000 lines of non-header C++ code, with 500 op= uses and
about 1125 uses of ++ or --.

Re: += in ada

[(see below)]

On 20/10/03 14:00, in article 1066654831.617492@master.nyc.kbcfp.com, "Hyman
Rosen" <hyrosen@mail.com> wrote:

> It's not the whole system, for which we don't have source,
> just the add-ons we ourselves have written. There's about
> 70000 lines of non-header C++ code, with 500 op= uses and
> about 1125 uses of ++ or --.

Interesting.

I grepped about 14_000 lines of my own Ada code (including specs) and found
about 100 potential uses of += 1, a ratio of 1 per 140 lines of source.
Hyman's ++ figures indicate a ratio of around 1 per 60 lines. I suspect that
automatic incrementing in Ada for-loops accounts for a good part of the
difference. Neither number indicates a pressing need for the facility in
Ada. Loop convenience in C/++ is somewhat dependent on having either += or
++. Perhaps this accounts for a rather basic difference of perception.

To be fairer to Russ than he is to others, however, his concern goes well
beyond += 1. He wants an overloadable set of op= commands. (Possibly with
predefined array-handling versions?)

I think we have (sort of) an answer on the relatively minor question of the
need for temporaries in scalar op=. Robert and/or "Bob", does your opinion
on that differ vis-a-vis matrices (say).
-- 
Bill

Re: += in ada

[Chad R. Meiners]

"(see below)" <yaldnifb@blueyonder.co.uk> wrote in message
news:BBB9AF46.60D16%yaldnifb@blueyonder.co.uk...
> On 20/10/03 14:00, in article 1066654831.617492@master.nyc.kbcfp.com,
"Hyman
> Rosen" <hyrosen@mail.com> wrote:
>
> > It's not the whole system, for which we don't have source,
> > just the add-ons we ourselves have written. There's about
> > 70000 lines of non-header C++ code, with 500 op= uses and
> > about 1125 uses of ++ or --.
>
> Interesting.
>
> I grepped about 14_000 lines of my own Ada code (including specs) and
found
> about 100 potential uses of += 1, a ratio of 1 per 140 lines of source.
> Hyman's ++ figures indicate a ratio of around 1 per 60 lines. I suspect
that
> automatic incrementing in Ada for-loops accounts for a good part of the
> difference.

That or difference in purpose.  Business software tends to like accumulation
;-)

-CRM

Re: += in ada

[Russ]

"Mark A. Biggar" <mark@biggar.org> wrote in message news:<w%yjb.783830$YN5.775353@sccrnsc01>...
> Hyman Rosen wrote:
> 
> > Lutz Donnerhacke wrote:
> > 
> >> * Russ wrote:
> >>
> >>> Actually, a competent programmer will define the "+" operator in terms
> >>> of the ":+" operator rather than vice versa, because the ":+" is
> >>> usually more efficient (since it has no need for temporaries and extra
> >>> copying).
> >>
> >>
> >> Wrong.
> > 
> > 
> > That's certainly the way it's usually done in C++,
> > for exactly the reason stated, so a bald "wrong" is
> > not terribly enlightening.
> > 
> 
> Okay, show how to define "+" in terms of "+=" with out explicitly
> reintroducing the temp variable you were so hot to eliminate?

When you define "+" in terms of "+=" you reintroduce the temp, of
course. The point is that you then have the option of using "+=",
which is more efficient, or "+", which is a bit more elegant. Also,
"+" can be "cascaded", as in "A = B + C + D", but "+=" cannot (you
need A=B; A+=C; A+=D).

Re: += in ada

[Lutz Donnerhacke]

* Hyman Rosen wrote:
> Lutz Donnerhacke wrote:
>> * Russ wrote:
>>>Actually, a competent programmer will define the "+" operator in terms
>>>of the ":+" operator rather than vice versa, because the ":+" is
>>>usually more efficient (since it has no need for temporaries and extra
>>>copying).
>>
>> Wrong.
>
> That's certainly the way it's usually done in C++,
> for exactly the reason stated, so a bald "wrong" is
> not terribly enlightening.

Augmented assigments need a temporary as well as ordinary assigments of
simple expressions. So your claim about unnecessary temporaries is plain
wrong.

Re: += in ada

[Hyman Rosen]

Lutz Donnerhacke wrote:
> Augmented assigments need a temporary as well as ordinary assigments of
> simple expressions. So your claim about unnecessary temporaries is plain
> wrong.

If you're talking about Ada, augmented assignment operators don't
exist, so they cannot need anything. It's equally accurate to say
that every legal use of an augmented assignment operator in Ada
requires the sacrifice of a goat.

If Ada were augmented with augmented assignment operators, I imagine
their specifications would not be so deliberately obtuse as to require
what you are suggesting. Augmented assignment operators would get the
target of the assignment as an 'in out' parameter, at least in the
user-defined case. For built-in arithmetic, it hardly matters; there
it's the notational convenience that's desired, not the efficiency.

Re: += in ada

[Lutz Donnerhacke]

* Hyman Rosen wrote:
> Lutz Donnerhacke wrote:
>> Augmented assigments need a temporary as well as ordinary assigments of
>> simple expressions. So your claim about unnecessary temporaries is plain
>> wrong.
>
> If you're talking about Ada, augmented assignment operators don't
> exist, so they cannot need anything. It's equally accurate to say
> that every legal use of an augmented assignment operator in Ada
> requires the sacrifice of a goat.

It's silly to propose new syntactic elements that differs too much from the
existing language. YMMV. I'd recomment "alias gnat=g++".

Re: += in ada

[Hyman Rosen]

Lutz Donnerhacke wrote:
> It's silly to propose new syntactic elements that differs too much from the
> existing language. YMMV. I'd recomment "alias gnat=g++".

I'm not proposing anything. But it's equally silly to adopt
new syntactic elements and render at least some of their
potential benefits useless.

Re: += in ada

[Larry Kilgallen]

In article <1066400493.692750@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Lutz Donnerhacke wrote:
>> Augmented assigments need a temporary as well as ordinary assigments of
>> simple expressions. So your claim about unnecessary temporaries is plain
>> wrong.
> 
> If you're talking about Ada, augmented assignment operators don't
> exist, so they cannot need anything. It's equally accurate to say
> that every legal use of an augmented assignment operator in Ada
> requires the sacrifice of a goat.

But _illegal_ use of an augmented assignment operator in Ada requires
two goats :-)

Re: += in ada

[Robert I. Eachus]

Hyman Rosen wrote:

> If you're talking about Ada, augmented assignment operators don't
> exist, so they cannot need anything. It's equally accurate to say
> that every legal use of an augmented assignment operator in Ada
> requires the sacrifice of a goat.

I wish we had a way to recommend posts here, so I could recommend yours.

> If Ada were augmented with augmented assignment operators, I imagine
> their specifications would not be so deliberately obtuse as to require
> what you are suggesting. Augmented assignment operators would get the
> target of the assignment as an 'in out' parameter, at least in the
> user-defined case. For built-in arithmetic, it hardly matters; there
> it's the notational convenience that's desired, not the efficiency.

If you look at what I said in another thread, I think we are on to 
something.  Addding += (or whatever notation) to Ada is a non-starter. 
It won't happen.  But we are discussing the wrong C notation when we 
discuss +=.  The real analog to Inc is ++.  Adding Foo++ to Ada won't 
happen either, but ++Foo; is not totally crazy, and clearly corresponds 
to Inc(Foo); which I think everyone recognizes is reasonable Ada, just 
not currently predefined.

How much effort would it be to add it to Ada?  Good question.  For the 
predefined integer and character types, it would be trivial.  (Add a few 
declarations to Standard.) Adding it as a predefined operation for all 
integer and enumeration types would be a lot more effort, but not out of 
the scope of a language revision like the one currently underway.

I am certainly not going to suggest adding Inc to Ada 200X.  IMHO, there 
are many more important additions to the language, and not all of them 
will make it in due to time and resource limitations.  But if you think 
that Inc (or ++) is important, go for it.  But as for += and its 
brothers, that would just be wasting everyone's time.

-- 
                                       Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: += in ada

[Chad R. Meiners]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F90128B.3050805@comcast.net...

> I am certainly not going to suggest adding Inc to Ada 200X.  IMHO, there
> are many more important additions to the language, and not all of them
> will make it in due to time and resource limitations.  But if you think
> that Inc (or ++) is important, go for it.  But as for += and its
> brothers, that would just be wasting everyone's time.

So, instead, how about a set of generic packages that provide the
functionality, which can be with'd and use'd?  Such a set of packages could
be placed on a publicly available server and evolve into a de facto
standard.

-CRM

Re: += in ada

[Vinzent 'Gadget' Hoefler]

Stuart Palin wrote:

>Treating them as operator functions in their own right seems
>to create difficulties in defining a workable specification
>for the function

It wouldn't even be a function. Functions in Ada can only have
parameters of mode "in". A ":+=" would have one of "in out".

>I suppose the other option would be to treat them not as
>operators but as "assignments" (and so not support renaming
>on post-fix notation)

Well, AFAICS overloading/renaming raises another issue. I tried to
explain that in <news:bmk7hs$nnim8$1@ID-175126.news.uni-berlin.de>.


Vinzent.