* += in ada @ 2003-09-25 16:25 Dmytry Lavrov 2003-10-01 8:35 ` Peter Amey 2003-10-01 14:06 ` Gautier 0 siblings, 2 replies; 274+ messages in thread From: Dmytry Lavrov @ 2003-09-25 16:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-09-25 16:25 += in ada Dmytry Lavrov @ 2003-10-01 8:35 ` Peter Amey 2003-10-01 12:38 ` Frank J. Lhota 2003-10-04 20:17 ` Craig Carey 2003-10-01 14:06 ` Gautier 1 sibling, 2 replies; 274+ messages in thread From: Peter Amey @ 2003-10-01 8:35 UTC (permalink / raw) >> >> 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-01 8:35 ` Peter Amey @ 2003-10-01 12:38 ` Frank J. Lhota 2003-10-03 16:22 ` Isaac Gouy 2003-10-04 20:17 ` Craig Carey 1 sibling, 1 reply; 274+ messages in thread From: Frank J. Lhota @ 2003-10-01 12:38 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-01 12:38 ` Frank J. Lhota @ 2003-10-03 16:22 ` Isaac Gouy 2003-10-06 20:21 ` Russ 0 siblings, 1 reply; 274+ messages in thread From: Isaac Gouy @ 2003-10-03 16:22 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-03 16:22 ` Isaac Gouy @ 2003-10-06 20:21 ` Russ 2003-10-06 22:47 ` (see below) 0 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-06 20:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-06 20:21 ` Russ @ 2003-10-06 22:47 ` (see below) 0 siblings, 0 replies; 274+ messages in thread From: (see below) @ 2003-10-06 22:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-01 8:35 ` Peter Amey 2003-10-01 12:38 ` Frank J. Lhota @ 2003-10-04 20:17 ` Craig Carey 2003-10-06 7:36 ` Jean-Pierre Rosen 1 sibling, 1 reply; 274+ messages in thread From: Craig Carey @ 2003-10-04 20:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-04 20:17 ` Craig Carey @ 2003-10-06 7:36 ` Jean-Pierre Rosen 2003-10-06 8:13 ` Lutz Donnerhacke 2003-10-06 22:49 ` Wes Groleau 0 siblings, 2 replies; 274+ messages in thread From: Jean-Pierre Rosen @ 2003-10-06 7:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-06 7:36 ` Jean-Pierre Rosen @ 2003-10-06 8:13 ` Lutz Donnerhacke 2003-10-06 22:49 ` Wes Groleau 1 sibling, 0 replies; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-06 8:13 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-06 7:36 ` Jean-Pierre Rosen 2003-10-06 8:13 ` Lutz Donnerhacke @ 2003-10-06 22:49 ` Wes Groleau 1 sibling, 0 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-06 22:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-09-25 16:25 += in ada Dmytry Lavrov 2003-10-01 8:35 ` Peter Amey @ 2003-10-01 14:06 ` Gautier 2003-10-02 12:26 ` Lutz Donnerhacke 2003-10-14 9:52 ` += in ada Stuart Palin 1 sibling, 2 replies; 274+ messages in thread From: Gautier @ 2003-10-01 14:06 UTC (permalink / raw) # > 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-01 14:06 ` Gautier @ 2003-10-02 12:26 ` Lutz Donnerhacke 2003-10-02 13:03 ` Preben Randhol 2003-10-14 9:52 ` += in ada Stuart Palin 1 sibling, 1 reply; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-02 12:26 UTC (permalink / raw) * 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-02 12:26 ` Lutz Donnerhacke @ 2003-10-02 13:03 ` Preben Randhol 2003-10-02 13:36 ` Lutz Donnerhacke 2003-10-20 7:41 ` idem (Was: += in ada) Jacob Sparre Andersen 0 siblings, 2 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-02 13:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-02 13:03 ` Preben Randhol @ 2003-10-02 13:36 ` Lutz Donnerhacke 2003-10-02 21:28 ` Keith Thompson 2003-10-20 7:41 ` idem (Was: += in ada) Jacob Sparre Andersen 1 sibling, 1 reply; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-02 13:36 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-02 13:36 ` Lutz Donnerhacke @ 2003-10-02 21:28 ` Keith Thompson 2003-10-07 0:41 ` Russ 0 siblings, 1 reply; 274+ messages in thread From: Keith Thompson @ 2003-10-02 21:28 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-02 21:28 ` Keith Thompson @ 2003-10-07 0:41 ` Russ 2003-10-07 10:05 ` Dmytry Lavrov 0 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-07 0:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-07 0:41 ` Russ @ 2003-10-07 10:05 ` Dmytry Lavrov 2003-10-07 11:56 ` Lutz Donnerhacke 0 siblings, 1 reply; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-07 10:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-07 10:05 ` Dmytry Lavrov @ 2003-10-07 11:56 ` Lutz Donnerhacke 2003-10-07 14:02 ` (see below) 2003-10-07 18:28 ` Alexander Kopilovitch 0 siblings, 2 replies; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-07 11:56 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-07 11:56 ` Lutz Donnerhacke @ 2003-10-07 14:02 ` (see below) 2003-10-07 22:22 ` Russ 2003-10-07 18:28 ` Alexander Kopilovitch 1 sibling, 1 reply; 274+ messages in thread From: (see below) @ 2003-10-07 14:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-07 14:02 ` (see below) @ 2003-10-07 22:22 ` Russ 2003-10-07 23:52 ` (see below) 2003-10-08 6:08 ` Preben Randhol 0 siblings, 2 replies; 274+ messages in thread From: Russ @ 2003-10-07 22:22 UTC (permalink / raw) "(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? ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-07 22:22 ` Russ @ 2003-10-07 23:52 ` (see below) 2003-10-08 6:08 ` Preben Randhol 1 sibling, 0 replies; 274+ messages in thread From: (see below) @ 2003-10-07 23:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-07 22:22 ` Russ 2003-10-07 23:52 ` (see below) @ 2003-10-08 6:08 ` Preben Randhol 2003-10-09 19:07 ` Russ 1 sibling, 1 reply; 274+ messages in thread From: Preben Randhol @ 2003-10-08 6:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-08 6:08 ` Preben Randhol @ 2003-10-09 19:07 ` Russ 2003-10-09 19:42 ` Vinzent 'Gadget' Hoefler ` (2 more replies) 0 siblings, 3 replies; 274+ messages in thread From: Russ @ 2003-10-09 19:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-09 19:07 ` Russ @ 2003-10-09 19:42 ` Vinzent 'Gadget' Hoefler [not found] ` <25oh51-uu2.ln1@beastie.ix.netcom.com> 2003-10-10 7:34 ` Preben Randhol 2003-10-10 20:31 ` += in ada Dmytry Lavrov 2 siblings, 1 reply; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-09 19:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
[parent not found: <25oh51-uu2.ln1@beastie.ix.netcom.com>]
* Re: += in ada [not found] ` <25oh51-uu2.ln1@beastie.ix.netcom.com> @ 2003-10-10 7:37 ` Preben Randhol 2003-10-10 18:56 ` Russ 2003-10-10 12:09 ` Vinzent 'Gadget' Hoefler 1 sibling, 1 reply; 274+ messages in thread From: Preben Randhol @ 2003-10-10 7:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-10 7:37 ` Preben Randhol @ 2003-10-10 18:56 ` Russ 2003-10-11 8:10 ` Preben Randhol 2003-10-11 8:30 ` Samuel Tardieu 0 siblings, 2 replies; 274+ messages in thread From: Russ @ 2003-10-10 18:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-10 18:56 ` Russ @ 2003-10-11 8:10 ` Preben Randhol 2003-10-11 8:30 ` Samuel Tardieu 1 sibling, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-11 8:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-10 18:56 ` Russ 2003-10-11 8:10 ` Preben Randhol @ 2003-10-11 8:30 ` Samuel Tardieu 1 sibling, 0 replies; 274+ messages in thread From: Samuel Tardieu @ 2003-10-11 8:30 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada [not found] ` <25oh51-uu2.ln1@beastie.ix.netcom.com> 2003-10-10 7:37 ` Preben Randhol @ 2003-10-10 12:09 ` Vinzent 'Gadget' Hoefler 1 sibling, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-10 12:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-09 19:07 ` Russ 2003-10-09 19:42 ` Vinzent 'Gadget' Hoefler @ 2003-10-10 7:34 ` Preben Randhol 2003-10-12 0:50 ` Wes Groleau 2003-10-10 20:31 ` += in ada Dmytry Lavrov 2 siblings, 1 reply; 274+ messages in thread From: Preben Randhol @ 2003-10-10 7:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-10 7:34 ` Preben Randhol @ 2003-10-12 0:50 ` Wes Groleau 2003-10-12 8:24 ` Preben Randhol 0 siblings, 1 reply; 274+ messages in thread From: Wes Groleau @ 2003-10-12 0:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-12 0:50 ` Wes Groleau @ 2003-10-12 8:24 ` Preben Randhol 2003-10-12 14:57 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Preben Randhol @ 2003-10-12 8:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-12 8:24 ` Preben Randhol @ 2003-10-12 14:57 ` Robert I. Eachus 2003-10-12 18:37 ` (see below) 0 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-12 14:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-12 14:57 ` Robert I. Eachus @ 2003-10-12 18:37 ` (see below) 2003-10-13 0:42 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: (see below) @ 2003-10-12 18:37 UTC (permalink / raw) 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 (":" => "") ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-12 18:37 ` (see below) @ 2003-10-13 0:42 ` Robert I. Eachus 2003-10-13 8:32 ` Dmytry Lavrov ` (2 more replies) 0 siblings, 3 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-13 0:42 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-13 0:42 ` Robert I. Eachus @ 2003-10-13 8:32 ` Dmytry Lavrov 2003-10-13 19:18 ` Robert I. Eachus 2003-10-13 23:36 ` Alexandre E. Kopilovitch 2003-10-30 21:43 ` ARG process (was += in ada) Randy Brukardt 2 siblings, 1 reply; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-13 8:32 UTC (permalink / raw) "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) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-13 8:32 ` Dmytry Lavrov @ 2003-10-13 19:18 ` Robert I. Eachus 0 siblings, 0 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-13 19:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-13 0:42 ` Robert I. Eachus 2003-10-13 8:32 ` Dmytry Lavrov @ 2003-10-13 23:36 ` Alexandre E. Kopilovitch 2003-10-14 6:14 ` Vinzent 'Gadget' Hoefler 2003-10-30 21:43 ` ARG process (was += in ada) Randy Brukardt 2 siblings, 1 reply; 274+ messages in thread From: Alexandre E. Kopilovitch @ 2003-10-13 23:36 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-13 23:36 ` Alexandre E. Kopilovitch @ 2003-10-14 6:14 ` Vinzent 'Gadget' Hoefler 2003-10-14 15:19 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-14 6:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-14 6:14 ` Vinzent 'Gadget' Hoefler @ 2003-10-14 15:19 ` Robert I. Eachus 0 siblings, 0 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-14 15:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: ARG process (was += in ada) 2003-10-13 0:42 ` Robert I. Eachus 2003-10-13 8:32 ` Dmytry Lavrov 2003-10-13 23:36 ` Alexandre E. Kopilovitch @ 2003-10-30 21:43 ` Randy Brukardt 2003-10-30 23:21 ` Robert I. Eachus 2 siblings, 1 reply; 274+ messages in thread From: Randy Brukardt @ 2003-10-30 21:43 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: ARG process (was += in ada) 2003-10-30 21:43 ` ARG process (was += in ada) Randy Brukardt @ 2003-10-30 23:21 ` Robert I. Eachus 0 siblings, 0 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-30 23:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-09 19:07 ` Russ 2003-10-09 19:42 ` Vinzent 'Gadget' Hoefler 2003-10-10 7:34 ` Preben Randhol @ 2003-10-10 20:31 ` Dmytry Lavrov 2003-10-12 8:23 ` Dmytry Lavrov 2003-10-14 18:00 ` Russ 2 siblings, 2 replies; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-10 20:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-10 20:31 ` += in ada Dmytry Lavrov @ 2003-10-12 8:23 ` Dmytry Lavrov 2003-10-14 18:00 ` Russ 1 sibling, 0 replies; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-12 8:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-10 20:31 ` += in ada Dmytry Lavrov 2003-10-12 8:23 ` Dmytry Lavrov @ 2003-10-14 18:00 ` Russ 2003-10-14 18:15 ` Vinzent 'Gadget' Hoefler ` (3 more replies) 1 sibling, 4 replies; 274+ messages in thread From: Russ @ 2003-10-14 18:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-14 18:00 ` Russ @ 2003-10-14 18:15 ` Vinzent 'Gadget' Hoefler 2003-10-15 12:50 ` Georg Bauhaus ` (2 subsequent siblings) 3 siblings, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-14 18:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-14 18:00 ` Russ 2003-10-14 18:15 ` Vinzent 'Gadget' Hoefler @ 2003-10-15 12:50 ` Georg Bauhaus 2003-10-15 13:25 ` Hyman Rosen 2003-10-16 4:04 ` += " Russ 2003-10-15 14:16 ` Dmytry Lavrov 2003-10-16 1:25 ` Chad R. Meiners 3 siblings, 2 replies; 274+ messages in thread From: Georg Bauhaus @ 2003-10-15 12:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 12:50 ` Georg Bauhaus @ 2003-10-15 13:25 ` Hyman Rosen 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler 2003-10-16 4:04 ` += " Russ 1 sibling, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-15 13:25 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 13:25 ` Hyman Rosen @ 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler 2003-10-15 15:19 ` Hyman Rosen 2003-10-16 4:31 ` + " Russ 0 siblings, 2 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-15 14:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler @ 2003-10-15 15:19 ` Hyman Rosen 2003-10-15 18:06 ` Vinzent 'Gadget' Hoefler 2003-10-16 5:05 ` Russ 2003-10-16 4:31 ` + " Russ 1 sibling, 2 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-15 15:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 15:19 ` Hyman Rosen @ 2003-10-15 18:06 ` Vinzent 'Gadget' Hoefler 2003-10-15 18:53 ` Hyman Rosen 2003-10-16 5:05 ` Russ 1 sibling, 1 reply; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-15 18:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 18:06 ` Vinzent 'Gadget' Hoefler @ 2003-10-15 18:53 ` Hyman Rosen 2003-10-15 19:34 ` Vinzent 'Gadget' Hoefler 2003-10-15 23:09 ` Alexandre E. Kopilovitch 0 siblings, 2 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-15 18:53 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 18:53 ` Hyman Rosen @ 2003-10-15 19:34 ` Vinzent 'Gadget' Hoefler 2003-10-15 23:09 ` Alexandre E. Kopilovitch 1 sibling, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-15 19:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 18:53 ` Hyman Rosen 2003-10-15 19:34 ` Vinzent 'Gadget' Hoefler @ 2003-10-15 23:09 ` Alexandre E. Kopilovitch 1 sibling, 0 replies; 274+ messages in thread From: Alexandre E. Kopilovitch @ 2003-10-15 23:09 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 15:19 ` Hyman Rosen 2003-10-15 18:06 ` Vinzent 'Gadget' Hoefler @ 2003-10-16 5:05 ` Russ 2003-10-16 12:07 ` Marin David Condic 2003-10-16 13:43 ` Hyman Rosen 1 sibling, 2 replies; 274+ messages in thread From: Russ @ 2003-10-16 5:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 5:05 ` Russ @ 2003-10-16 12:07 ` Marin David Condic 2003-10-16 13:43 ` Hyman Rosen 1 sibling, 0 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-16 12:07 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 5:05 ` Russ 2003-10-16 12:07 ` Marin David Condic @ 2003-10-16 13:43 ` Hyman Rosen 2003-10-16 23:57 ` Robert I. Eachus 1 sibling, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-16 13:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 13:43 ` Hyman Rosen @ 2003-10-16 23:57 ` Robert I. Eachus 2003-10-17 6:22 ` Russ 0 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-16 23:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 23:57 ` Robert I. Eachus @ 2003-10-17 6:22 ` Russ 2003-10-17 6:38 ` Preben Randhol 2003-10-17 15:48 ` Robert I. Eachus 0 siblings, 2 replies; 274+ messages in thread From: Russ @ 2003-10-17 6:22 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 6:22 ` Russ @ 2003-10-17 6:38 ` Preben Randhol 2003-10-17 15:48 ` Robert I. Eachus 1 sibling, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-17 6:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 6:22 ` Russ 2003-10-17 6:38 ` Preben Randhol @ 2003-10-17 15:48 ` Robert I. Eachus 2003-10-19 1:15 ` Russ 2003-10-19 22:26 ` Wes Groleau 1 sibling, 2 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-17 15:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 15:48 ` Robert I. Eachus @ 2003-10-19 1:15 ` Russ 2003-10-19 16:04 ` Robert I. Eachus ` (2 more replies) 2003-10-19 22:26 ` Wes Groleau 1 sibling, 3 replies; 274+ messages in thread From: Russ @ 2003-10-19 1:15 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:15 ` Russ @ 2003-10-19 16:04 ` Robert I. Eachus 2003-10-19 23:59 ` Russ 2003-10-19 23:19 ` Robert A Duff 2003-10-21 2:43 ` Alexandre E. Kopilovitch 2 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-19 16:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 16:04 ` Robert I. Eachus @ 2003-10-19 23:59 ` Russ 2003-10-20 5:24 ` Chad R. Meiners 0 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-19 23:59 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 23:59 ` Russ @ 2003-10-20 5:24 ` Chad R. Meiners 2003-10-20 5:52 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Chad R. Meiners @ 2003-10-20 5:24 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 5:24 ` Chad R. Meiners @ 2003-10-20 5:52 ` Robert I. Eachus 2003-10-20 12:40 ` Marin David Condic ` (2 more replies) 0 siblings, 3 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-20 5:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 5:52 ` Robert I. Eachus @ 2003-10-20 12:40 ` Marin David Condic 2003-10-20 14:36 ` Preben Randhol ` (2 more replies) 2003-10-20 14:34 ` Preben Randhol 2003-10-21 7:43 ` Russ 2 siblings, 3 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-20 12:40 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 12:40 ` Marin David Condic @ 2003-10-20 14:36 ` Preben Randhol 2003-10-21 0:23 ` Wes Groleau 2003-10-21 6:37 ` Russ 2 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-20 14:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 12:40 ` Marin David Condic 2003-10-20 14:36 ` Preben Randhol @ 2003-10-21 0:23 ` Wes Groleau 2003-10-21 3:46 ` Hyman Rosen 2003-10-21 6:37 ` Russ 2 siblings, 1 reply; 274+ messages in thread From: Wes Groleau @ 2003-10-21 0:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 0:23 ` Wes Groleau @ 2003-10-21 3:46 ` Hyman Rosen 0 siblings, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-21 3:46 UTC (permalink / raw) Wes Groleau wrote: > Isn't that how C++ got to where it is today? Yep. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 12:40 ` Marin David Condic 2003-10-20 14:36 ` Preben Randhol 2003-10-21 0:23 ` Wes Groleau @ 2003-10-21 6:37 ` Russ 2003-10-21 10:10 ` Marius Amado Alves 2 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-21 6:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 6:37 ` Russ @ 2003-10-21 10:10 ` Marius Amado Alves 2003-10-22 5:23 ` Russ 0 siblings, 1 reply; 274+ messages in thread From: Marius Amado Alves @ 2003-10-21 10:10 UTC (permalink / raw) To: comp.lang.ada 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.) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 10:10 ` Marius Amado Alves @ 2003-10-22 5:23 ` Russ 0 siblings, 0 replies; 274+ messages in thread From: Russ @ 2003-10-22 5:23 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 5:52 ` Robert I. Eachus 2003-10-20 12:40 ` Marin David Condic @ 2003-10-20 14:34 ` Preben Randhol 2003-10-21 7:43 ` Russ 2 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-20 14:34 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 5:52 ` Robert I. Eachus 2003-10-20 12:40 ` Marin David Condic 2003-10-20 14:34 ` Preben Randhol @ 2003-10-21 7:43 ` Russ 2003-10-21 12:45 ` Lutz Donnerhacke 2003-10-21 13:38 ` Robert I. Eachus 2 siblings, 2 replies; 274+ messages in thread From: Russ @ 2003-10-21 7:43 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 7:43 ` Russ @ 2003-10-21 12:45 ` Lutz Donnerhacke 2003-10-22 7:13 ` Russ 2003-10-22 8:01 ` Russ 2003-10-21 13:38 ` Robert I. Eachus 1 sibling, 2 replies; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-21 12:45 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 12:45 ` Lutz Donnerhacke @ 2003-10-22 7:13 ` Russ 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler ` (2 more replies) 2003-10-22 8:01 ` Russ 1 sibling, 3 replies; 274+ messages in thread From: Russ @ 2003-10-22 7:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 7:13 ` Russ @ 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler 2003-10-22 9:02 ` Lutz Donnerhacke 2003-10-22 9:46 ` Preben Randhol 2 siblings, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-22 8:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 7:13 ` Russ 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler @ 2003-10-22 9:02 ` Lutz Donnerhacke 2003-10-22 18:21 ` Russ 2003-10-22 21:22 ` Russ 2003-10-22 9:46 ` Preben Randhol 2 siblings, 2 replies; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-22 9:02 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 9:02 ` Lutz Donnerhacke @ 2003-10-22 18:21 ` Russ 2003-10-22 19:10 ` Vinzent 'Gadget' Hoefler 2003-10-22 19:16 ` += " sk 2003-10-22 21:22 ` Russ 1 sibling, 2 replies; 274+ messages in thread From: Russ @ 2003-10-22 18:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 18:21 ` Russ @ 2003-10-22 19:10 ` Vinzent 'Gadget' Hoefler 2003-10-23 5:24 ` + " Russ 2003-10-22 19:16 ` += " sk 1 sibling, 1 reply; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-22 19:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: + in ada 2003-10-22 19:10 ` Vinzent 'Gadget' Hoefler @ 2003-10-23 5:24 ` Russ 0 siblings, 0 replies; 274+ messages in thread From: Russ @ 2003-10-23 5:24 UTC (permalink / raw) 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'. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 18:21 ` Russ 2003-10-22 19:10 ` Vinzent 'Gadget' Hoefler @ 2003-10-22 19:16 ` sk 2003-10-22 19:13 ` Vinzent 'Gadget' Hoefler 2003-10-23 5:16 ` Russ 1 sibling, 2 replies; 274+ messages in thread From: sk @ 2003-10-22 19:16 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 19:16 ` += " sk @ 2003-10-22 19:13 ` Vinzent 'Gadget' Hoefler 2003-10-23 5:16 ` Russ 1 sibling, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-22 19:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 19:16 ` += " sk 2003-10-22 19:13 ` Vinzent 'Gadget' Hoefler @ 2003-10-23 5:16 ` Russ 2003-10-23 5:45 ` sk 1 sibling, 1 reply; 274+ messages in thread From: Russ @ 2003-10-23 5:16 UTC (permalink / raw) 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. :-) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-23 5:16 ` Russ @ 2003-10-23 5:45 ` sk 0 siblings, 0 replies; 274+ messages in thread From: sk @ 2003-10-23 5:45 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 9:02 ` Lutz Donnerhacke 2003-10-22 18:21 ` Russ @ 2003-10-22 21:22 ` Russ 2003-10-23 2:23 ` Wes Groleau 1 sibling, 1 reply; 274+ messages in thread From: Russ @ 2003-10-22 21:22 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 21:22 ` Russ @ 2003-10-23 2:23 ` Wes Groleau 0 siblings, 0 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-23 2:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 7:13 ` Russ 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler 2003-10-22 9:02 ` Lutz Donnerhacke @ 2003-10-22 9:46 ` Preben Randhol 2 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-22 9:46 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 12:45 ` Lutz Donnerhacke 2003-10-22 7:13 ` Russ @ 2003-10-22 8:01 ` Russ 1 sibling, 0 replies; 274+ messages in thread From: Russ @ 2003-10-22 8:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 7:43 ` Russ 2003-10-21 12:45 ` Lutz Donnerhacke @ 2003-10-21 13:38 ` Robert I. Eachus 2003-10-22 7:24 ` Russ 1 sibling, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-21 13:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 13:38 ` Robert I. Eachus @ 2003-10-22 7:24 ` Russ 2003-10-22 19:50 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-22 7:24 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 7:24 ` Russ @ 2003-10-22 19:50 ` Robert I. Eachus 2003-10-23 5:34 ` Russ 0 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-22 19:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 19:50 ` Robert I. Eachus @ 2003-10-23 5:34 ` Russ 2003-10-23 14:14 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-23 5:34 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-23 5:34 ` Russ @ 2003-10-23 14:14 ` Robert I. Eachus 2003-10-24 9:15 ` Peter Hermann 2003-10-25 5:07 ` Russ 0 siblings, 2 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-23 14:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-23 14:14 ` Robert I. Eachus @ 2003-10-24 9:15 ` Peter Hermann 2003-10-24 10:11 ` Marius Amado Alves ` (2 more replies) 2003-10-25 5:07 ` Russ 1 sibling, 3 replies; 274+ messages in thread From: Peter Hermann @ 2003-10-24 9:15 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-24 9:15 ` Peter Hermann @ 2003-10-24 10:11 ` Marius Amado Alves 2003-10-26 7:35 ` Pascal Obry 2003-10-24 11:20 ` Marin David Condic 2003-10-25 3:14 ` Russ 2 siblings, 1 reply; 274+ messages in thread From: Marius Amado Alves @ 2003-10-24 10:11 UTC (permalink / raw) To: comp.lang.ada 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-24 10:11 ` Marius Amado Alves @ 2003-10-26 7:35 ` Pascal Obry 0 siblings, 0 replies; 274+ messages in thread From: Pascal Obry @ 2003-10-26 7:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-24 9:15 ` Peter Hermann 2003-10-24 10:11 ` Marius Amado Alves @ 2003-10-24 11:20 ` Marin David Condic 2003-10-25 3:14 ` Russ 2 siblings, 0 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-24 11:20 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-24 9:15 ` Peter Hermann 2003-10-24 10:11 ` Marius Amado Alves 2003-10-24 11:20 ` Marin David Condic @ 2003-10-25 3:14 ` Russ 2 siblings, 0 replies; 274+ messages in thread From: Russ @ 2003-10-25 3:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-23 14:14 ` Robert I. Eachus 2003-10-24 9:15 ` Peter Hermann @ 2003-10-25 5:07 ` Russ 1 sibling, 0 replies; 274+ messages in thread From: Russ @ 2003-10-25 5:07 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:15 ` Russ 2003-10-19 16:04 ` Robert I. Eachus @ 2003-10-19 23:19 ` Robert A Duff 2003-10-20 6:16 ` Russ 2003-10-21 2:43 ` Alexandre E. Kopilovitch 2 siblings, 1 reply; 274+ messages in thread From: Robert A Duff @ 2003-10-19 23:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 23:19 ` Robert A Duff @ 2003-10-20 6:16 ` Russ 2003-10-20 14:31 ` Preben Randhol ` (2 more replies) 0 siblings, 3 replies; 274+ messages in thread From: Russ @ 2003-10-20 6:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 6:16 ` Russ @ 2003-10-20 14:31 ` Preben Randhol 2003-10-20 17:10 ` Robert I. Eachus 2003-10-21 0:40 ` Wes Groleau 2 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-20 14:31 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 6:16 ` Russ 2003-10-20 14:31 ` Preben Randhol @ 2003-10-20 17:10 ` Robert I. Eachus 2003-10-20 17:53 ` Hyman Rosen 2003-10-21 0:40 ` Wes Groleau 2 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-20 17:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 17:10 ` Robert I. Eachus @ 2003-10-20 17:53 ` Hyman Rosen 2003-10-20 19:11 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-20 17:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 17:53 ` Hyman Rosen @ 2003-10-20 19:11 ` Robert I. Eachus 2003-10-20 19:32 ` Hyman Rosen 2003-10-20 23:24 ` Alexandre E. Kopilovitch 0 siblings, 2 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-20 19:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 19:11 ` Robert I. Eachus @ 2003-10-20 19:32 ` Hyman Rosen 2003-10-20 23:24 ` Alexandre E. Kopilovitch 1 sibling, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-20 19:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 19:11 ` Robert I. Eachus 2003-10-20 19:32 ` Hyman Rosen @ 2003-10-20 23:24 ` Alexandre E. Kopilovitch 1 sibling, 0 replies; 274+ messages in thread From: Alexandre E. Kopilovitch @ 2003-10-20 23:24 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 6:16 ` Russ 2003-10-20 14:31 ` Preben Randhol 2003-10-20 17:10 ` Robert I. Eachus @ 2003-10-21 0:40 ` Wes Groleau 2003-10-21 3:45 ` Hyman Rosen 2 siblings, 1 reply; 274+ messages in thread From: Wes Groleau @ 2003-10-21 0:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 0:40 ` Wes Groleau @ 2003-10-21 3:45 ` Hyman Rosen 2003-10-21 12:07 ` Preben Randhol ` (2 more replies) 0 siblings, 3 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-21 3:45 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 3:45 ` Hyman Rosen @ 2003-10-21 12:07 ` Preben Randhol 2003-10-21 12:18 ` Marius Amado Alves 2003-10-21 12:45 ` Marin David Condic [not found] ` <emte61-d03.ln1@beastie.ix.netcom.com> 2 siblings, 1 reply; 274+ messages in thread From: Preben Randhol @ 2003-10-21 12:07 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 12:07 ` Preben Randhol @ 2003-10-21 12:18 ` Marius Amado Alves 0 siblings, 0 replies; 274+ messages in thread From: Marius Amado Alves @ 2003-10-21 12:18 UTC (permalink / raw) To: comp.lang.ada 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.) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 3:45 ` Hyman Rosen 2003-10-21 12:07 ` Preben Randhol @ 2003-10-21 12:45 ` Marin David Condic 2003-10-21 14:46 ` Robert I. Eachus ` (2 more replies) [not found] ` <emte61-d03.ln1@beastie.ix.netcom.com> 2 siblings, 3 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-21 12:45 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 12:45 ` Marin David Condic @ 2003-10-21 14:46 ` Robert I. Eachus 2003-10-21 17:54 ` Chad R. Meiners ` (2 more replies) 2003-10-22 0:14 ` Wes Groleau 2003-10-22 6:56 ` += in ada Russ 2 siblings, 3 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-21 14:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:46 ` Robert I. Eachus @ 2003-10-21 17:54 ` Chad R. Meiners 2003-10-21 20:23 ` Robert I. Eachus 2003-10-22 0:18 ` Wes Groleau 2003-10-22 11:56 ` Marin David Condic 2 siblings, 1 reply; 274+ messages in thread From: Chad R. Meiners @ 2003-10-21 17:54 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 17:54 ` Chad R. Meiners @ 2003-10-21 20:23 ` Robert I. Eachus 0 siblings, 0 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-21 20:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:46 ` Robert I. Eachus 2003-10-21 17:54 ` Chad R. Meiners @ 2003-10-22 0:18 ` Wes Groleau 2003-10-22 4:07 ` Robert I. Eachus 2003-10-22 11:56 ` Marin David Condic 2 siblings, 1 reply; 274+ messages in thread From: Wes Groleau @ 2003-10-22 0:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 0:18 ` Wes Groleau @ 2003-10-22 4:07 ` Robert I. Eachus 2003-10-22 20:41 ` Wes Groleau 0 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-22 4:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 4:07 ` Robert I. Eachus @ 2003-10-22 20:41 ` Wes Groleau 0 siblings, 0 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-22 20:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:46 ` Robert I. Eachus 2003-10-21 17:54 ` Chad R. Meiners 2003-10-22 0:18 ` Wes Groleau @ 2003-10-22 11:56 ` Marin David Condic 2 siblings, 0 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-22 11:56 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 12:45 ` Marin David Condic 2003-10-21 14:46 ` Robert I. Eachus @ 2003-10-22 0:14 ` Wes Groleau 2003-10-22 12:31 ` Early Ada Mistakes (was: Re: += in ada) Marin David Condic 2003-10-22 6:56 ` += in ada Russ 2 siblings, 1 reply; 274+ messages in thread From: Wes Groleau @ 2003-10-22 0:14 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Early Ada Mistakes (was: Re: += in ada) 2003-10-22 0:14 ` Wes Groleau @ 2003-10-22 12:31 ` Marin David Condic 2003-10-22 20:05 ` Robert I. Eachus 2003-10-22 21:00 ` Wes Groleau 0 siblings, 2 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-22 12:31 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes (was: Re: += in ada) 2003-10-22 12:31 ` Early Ada Mistakes (was: Re: += in ada) Marin David Condic @ 2003-10-22 20:05 ` Robert I. Eachus 2003-10-23 4:47 ` Marin David Condic 2003-10-22 21:00 ` Wes Groleau 1 sibling, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-22 20:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes (was: Re: += in ada) 2003-10-22 20:05 ` Robert I. Eachus @ 2003-10-23 4:47 ` Marin David Condic 2003-10-23 14:36 ` Early Ada Mistakes Hyman Rosen 2003-10-23 18:50 ` Wes Groleau 0 siblings, 2 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-23 4:47 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-23 4:47 ` Marin David Condic @ 2003-10-23 14:36 ` Hyman Rosen 2003-10-23 19:04 ` Chad R. Meiners 2003-10-23 19:08 ` Wes Groleau 2003-10-23 18:50 ` Wes Groleau 1 sibling, 2 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-23 14:36 UTC (permalink / raw) 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>.) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-23 14:36 ` Early Ada Mistakes Hyman Rosen @ 2003-10-23 19:04 ` Chad R. Meiners 2003-10-24 13:33 ` Preben Randhol 2003-10-23 19:08 ` Wes Groleau 1 sibling, 1 reply; 274+ messages in thread From: Chad R. Meiners @ 2003-10-23 19:04 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-23 19:04 ` Chad R. Meiners @ 2003-10-24 13:33 ` Preben Randhol 2003-10-24 16:59 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Preben Randhol @ 2003-10-24 13:33 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-24 13:33 ` Preben Randhol @ 2003-10-24 16:59 ` Robert I. Eachus 0 siblings, 0 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-24 16:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-23 14:36 ` Early Ada Mistakes Hyman Rosen 2003-10-23 19:04 ` Chad R. Meiners @ 2003-10-23 19:08 ` Wes Groleau 2003-10-23 22:17 ` Robert I. Eachus 2003-10-24 11:26 ` Marin David Condic 1 sibling, 2 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-23 19:08 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-23 19:08 ` Wes Groleau @ 2003-10-23 22:17 ` Robert I. Eachus 2003-10-24 11:26 ` Marin David Condic 1 sibling, 0 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-23 22:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-23 19:08 ` Wes Groleau 2003-10-23 22:17 ` Robert I. Eachus @ 2003-10-24 11:26 ` Marin David Condic 1 sibling, 0 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-24 11:26 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-23 4:47 ` Marin David Condic 2003-10-23 14:36 ` Early Ada Mistakes Hyman Rosen @ 2003-10-23 18:50 ` Wes Groleau 1 sibling, 0 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-23 18:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-22 12:31 ` Early Ada Mistakes (was: Re: += in ada) Marin David Condic 2003-10-22 20:05 ` Robert I. Eachus @ 2003-10-22 21:00 ` Wes Groleau 2003-10-23 4:53 ` Marin David Condic 1 sibling, 1 reply; 274+ messages in thread From: Wes Groleau @ 2003-10-22 21:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes 2003-10-22 21:00 ` Wes Groleau @ 2003-10-23 4:53 ` Marin David Condic 0 siblings, 0 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-23 4:53 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 12:45 ` Marin David Condic 2003-10-21 14:46 ` Robert I. Eachus 2003-10-22 0:14 ` Wes Groleau @ 2003-10-22 6:56 ` Russ 2003-10-22 7:26 ` Preben Randhol ` (2 more replies) 2 siblings, 3 replies; 274+ messages in thread From: Russ @ 2003-10-22 6:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 6:56 ` += in ada Russ @ 2003-10-22 7:26 ` Preben Randhol 2003-10-22 11:27 ` Stephane Richard 2003-10-22 20:52 ` Wes Groleau 2 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-22 7:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 6:56 ` += in ada Russ 2003-10-22 7:26 ` Preben Randhol @ 2003-10-22 11:27 ` Stephane Richard 2003-10-22 20:12 ` Robert I. Eachus 2003-10-22 20:52 ` Wes Groleau 2 siblings, 1 reply; 274+ messages in thread From: Stephane Richard @ 2003-10-22 11:27 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 11:27 ` Stephane Richard @ 2003-10-22 20:12 ` Robert I. Eachus 0 siblings, 0 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-22 20:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 6:56 ` += in ada Russ 2003-10-22 7:26 ` Preben Randhol 2003-10-22 11:27 ` Stephane Richard @ 2003-10-22 20:52 ` Wes Groleau 2 siblings, 0 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-22 20:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
[parent not found: <emte61-d03.ln1@beastie.ix.netcom.com>]
* Re: += in ada [not found] ` <emte61-d03.ln1@beastie.ix.netcom.com> @ 2003-10-21 12:57 ` Hyman Rosen 0 siblings, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-21 12:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:15 ` Russ 2003-10-19 16:04 ` Robert I. Eachus 2003-10-19 23:19 ` Robert A Duff @ 2003-10-21 2:43 ` Alexandre E. Kopilovitch 2003-10-21 9:39 ` Stephane Richard 2 siblings, 1 reply; 274+ messages in thread From: Alexandre E. Kopilovitch @ 2003-10-21 2:43 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 2:43 ` Alexandre E. Kopilovitch @ 2003-10-21 9:39 ` Stephane Richard 0 siblings, 0 replies; 274+ messages in thread From: Stephane Richard @ 2003-10-21 9:39 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 15:48 ` Robert I. Eachus 2003-10-19 1:15 ` Russ @ 2003-10-19 22:26 ` Wes Groleau 1 sibling, 0 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-19 22:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: + in ada 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler 2003-10-15 15:19 ` Hyman Rosen @ 2003-10-16 4:31 ` Russ 2003-10-16 8:57 ` += " Vinzent 'Gadget' Hoefler 2003-10-16 20:56 ` + " Georg Bauhaus 1 sibling, 2 replies; 274+ messages in thread From: Russ @ 2003-10-16 4:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 4:31 ` + " Russ @ 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler 2003-10-16 20:56 ` + " Georg Bauhaus 1 sibling, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-16 8:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: + in ada 2003-10-16 4:31 ` + " Russ 2003-10-16 8:57 ` += " Vinzent 'Gadget' Hoefler @ 2003-10-16 20:56 ` Georg Bauhaus 1 sibling, 0 replies; 274+ messages in thread From: Georg Bauhaus @ 2003-10-16 20:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 12:50 ` Georg Bauhaus 2003-10-15 13:25 ` Hyman Rosen @ 2003-10-16 4:04 ` Russ 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler 2003-10-17 3:03 ` Wes Groleau 1 sibling, 2 replies; 274+ messages in thread From: Russ @ 2003-10-16 4:04 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 4:04 ` += " Russ @ 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler 2003-10-17 3:03 ` Wes Groleau 1 sibling, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-16 8:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 4:04 ` += " Russ 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler @ 2003-10-17 3:03 ` Wes Groleau 2003-10-17 11:46 ` Marin David Condic 1 sibling, 1 reply; 274+ messages in thread From: Wes Groleau @ 2003-10-17 3:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 3:03 ` Wes Groleau @ 2003-10-17 11:46 ` Marin David Condic 2003-10-17 11:50 ` Preben Randhol 0 siblings, 1 reply; 274+ messages in thread From: Marin David Condic @ 2003-10-17 11:46 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 11:46 ` Marin David Condic @ 2003-10-17 11:50 ` Preben Randhol 2003-10-17 12:40 ` sk 0 siblings, 1 reply; 274+ messages in thread From: Preben Randhol @ 2003-10-17 11:50 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 11:50 ` Preben Randhol @ 2003-10-17 12:40 ` sk 2003-10-17 12:48 ` Preben Randhol 0 siblings, 1 reply; 274+ messages in thread From: sk @ 2003-10-17 12:40 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 12:40 ` sk @ 2003-10-17 12:48 ` Preben Randhol 0 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-17 12:48 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-14 18:00 ` Russ 2003-10-14 18:15 ` Vinzent 'Gadget' Hoefler 2003-10-15 12:50 ` Georg Bauhaus @ 2003-10-15 14:16 ` Dmytry Lavrov 2003-10-16 5:40 ` Russ 2003-10-16 1:25 ` Chad R. Meiners 3 siblings, 1 reply; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-15 14:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-15 14:16 ` Dmytry Lavrov @ 2003-10-16 5:40 ` Russ 2003-10-16 12:45 ` Lutz Donnerhacke ` (2 more replies) 0 siblings, 3 replies; 274+ messages in thread From: Russ @ 2003-10-16 5:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 5:40 ` Russ @ 2003-10-16 12:45 ` Lutz Donnerhacke 2003-10-16 22:07 ` Russ 2003-10-16 13:48 ` Dmytry Lavrov 2003-10-16 20:46 ` Georg Bauhaus 2 siblings, 1 reply; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-16 12:45 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 12:45 ` Lutz Donnerhacke @ 2003-10-16 22:07 ` Russ 2003-10-17 9:10 ` Lutz Donnerhacke 0 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-16 22:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 22:07 ` Russ @ 2003-10-17 9:10 ` Lutz Donnerhacke 0 siblings, 0 replies; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-17 9:10 UTC (permalink / raw) * 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? ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 5:40 ` Russ 2003-10-16 12:45 ` Lutz Donnerhacke @ 2003-10-16 13:48 ` Dmytry Lavrov 2003-10-16 20:46 ` Georg Bauhaus 2 siblings, 0 replies; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-16 13:48 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 5:40 ` Russ 2003-10-16 12:45 ` Lutz Donnerhacke 2003-10-16 13:48 ` Dmytry Lavrov @ 2003-10-16 20:46 ` Georg Bauhaus 2003-10-17 2:37 ` Russ 2 siblings, 1 reply; 274+ messages in thread From: Georg Bauhaus @ 2003-10-16 20:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 20:46 ` Georg Bauhaus @ 2003-10-17 2:37 ` Russ 2003-10-17 3:01 ` sk ` (3 more replies) 0 siblings, 4 replies; 274+ messages in thread From: Russ @ 2003-10-17 2:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 2:37 ` Russ @ 2003-10-17 3:01 ` sk 2003-10-17 5:42 ` Russ 2003-10-17 3:52 ` Chad R. Meiners ` (2 subsequent siblings) 3 siblings, 1 reply; 274+ messages in thread From: sk @ 2003-10-17 3:01 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 3:01 ` sk @ 2003-10-17 5:42 ` Russ 2003-10-17 11:26 ` sk 0 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-17 5:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 5:42 ` Russ @ 2003-10-17 11:26 ` sk 2003-10-17 20:24 ` Dmytry Lavrov 0 siblings, 1 reply; 274+ messages in thread From: sk @ 2003-10-17 11:26 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 11:26 ` sk @ 2003-10-17 20:24 ` Dmytry Lavrov 0 siblings, 0 replies; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-17 20:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 2:37 ` Russ 2003-10-17 3:01 ` sk @ 2003-10-17 3:52 ` Chad R. Meiners 2003-10-17 6:32 ` Preben Randhol 2003-10-17 8:48 ` Dmytry Lavrov 3 siblings, 0 replies; 274+ messages in thread From: Chad R. Meiners @ 2003-10-17 3:52 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 2:37 ` Russ 2003-10-17 3:01 ` sk 2003-10-17 3:52 ` Chad R. Meiners @ 2003-10-17 6:32 ` Preben Randhol 2003-10-17 8:48 ` Dmytry Lavrov 3 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-17 6:32 UTC (permalink / raw) 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. :-) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 2:37 ` Russ ` (2 preceding siblings ...) 2003-10-17 6:32 ` Preben Randhol @ 2003-10-17 8:48 ` Dmytry Lavrov 3 siblings, 0 replies; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-17 8:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-14 18:00 ` Russ ` (2 preceding siblings ...) 2003-10-15 14:16 ` Dmytry Lavrov @ 2003-10-16 1:25 ` Chad R. Meiners 2003-10-19 23:50 ` Robert A Duff 3 siblings, 1 reply; 274+ messages in thread From: Chad R. Meiners @ 2003-10-16 1:25 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 1:25 ` Chad R. Meiners @ 2003-10-19 23:50 ` Robert A Duff 2003-10-20 5:52 ` Chad R. Meiners 0 siblings, 1 reply; 274+ messages in thread From: Robert A Duff @ 2003-10-19 23:50 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 23:50 ` Robert A Duff @ 2003-10-20 5:52 ` Chad R. Meiners 0 siblings, 0 replies; 274+ messages in thread From: Chad R. Meiners @ 2003-10-20 5:52 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-07 11:56 ` Lutz Donnerhacke 2003-10-07 14:02 ` (see below) @ 2003-10-07 18:28 ` Alexander Kopilovitch 2003-10-10 19:56 ` Dmytry Lavrov 1 sibling, 1 reply; 274+ messages in thread From: Alexander Kopilovitch @ 2003-10-07 18:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-07 18:28 ` Alexander Kopilovitch @ 2003-10-10 19:56 ` Dmytry Lavrov 0 siblings, 0 replies; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-10 19:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* idem (Was: += in ada) 2003-10-02 13:03 ` Preben Randhol 2003-10-02 13:36 ` Lutz Donnerhacke @ 2003-10-20 7:41 ` Jacob Sparre Andersen 2003-10-20 8:28 ` Dmitry A. Kazakov ` (2 more replies) 1 sibling, 3 replies; 274+ messages in thread From: Jacob Sparre Andersen @ 2003-10-20 7:41 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: idem (Was: += in ada) 2003-10-20 7:41 ` idem (Was: += in ada) Jacob Sparre Andersen @ 2003-10-20 8:28 ` Dmitry A. Kazakov 2003-10-20 8:34 ` (see below) 2003-10-31 22:40 ` Nick Roberts 2 siblings, 0 replies; 274+ messages in thread From: Dmitry A. Kazakov @ 2003-10-20 8:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: idem (Was: += in ada) 2003-10-20 7:41 ` idem (Was: += in ada) Jacob Sparre Andersen 2003-10-20 8:28 ` Dmitry A. Kazakov @ 2003-10-20 8:34 ` (see below) 2003-10-31 22:40 ` Nick Roberts 2 siblings, 0 replies; 274+ messages in thread From: (see below) @ 2003-10-20 8:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: idem (Was: += in ada) 2003-10-20 7:41 ` idem (Was: += in ada) Jacob Sparre Andersen 2003-10-20 8:28 ` Dmitry A. Kazakov 2003-10-20 8:34 ` (see below) @ 2003-10-31 22:40 ` Nick Roberts 2 siblings, 0 replies; 274+ messages in thread From: Nick Roberts @ 2003-10-31 22:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-01 14:06 ` Gautier 2003-10-02 12:26 ` Lutz Donnerhacke @ 2003-10-14 9:52 ` Stuart Palin 2003-10-16 8:49 ` Russ 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler 1 sibling, 2 replies; 274+ messages in thread From: Stuart Palin @ 2003-10-14 9:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-14 9:52 ` += in ada Stuart Palin @ 2003-10-16 8:49 ` Russ 2003-10-16 12:46 ` Lutz Donnerhacke 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler 1 sibling, 1 reply; 274+ messages in thread From: Russ @ 2003-10-16 8:49 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 8:49 ` Russ @ 2003-10-16 12:46 ` Lutz Donnerhacke 2003-10-16 13:46 ` Hyman Rosen 0 siblings, 1 reply; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-16 12:46 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 12:46 ` Lutz Donnerhacke @ 2003-10-16 13:46 ` Hyman Rosen 2003-10-16 15:42 ` Mark A. Biggar 2003-10-17 8:20 ` Lutz Donnerhacke 0 siblings, 2 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-16 13:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 13:46 ` Hyman Rosen @ 2003-10-16 15:42 ` Mark A. Biggar 2003-10-16 16:48 ` Hyman Rosen 2003-10-16 21:53 ` Russ 2003-10-17 8:20 ` Lutz Donnerhacke 1 sibling, 2 replies; 274+ messages in thread From: Mark A. Biggar @ 2003-10-16 15:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 15:42 ` Mark A. Biggar @ 2003-10-16 16:48 ` Hyman Rosen 2003-10-17 0:26 ` Robert I. Eachus 2003-10-16 21:53 ` Russ 1 sibling, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-16 16:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 16:48 ` Hyman Rosen @ 2003-10-17 0:26 ` Robert I. Eachus 2003-10-17 1:26 ` Marin David Condic 2003-10-17 14:15 ` Hyman Rosen 0 siblings, 2 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-17 0:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 0:26 ` Robert I. Eachus @ 2003-10-17 1:26 ` Marin David Condic 2003-10-17 3:59 ` Chad R. Meiners 2003-10-19 1:37 ` Russ 2003-10-17 14:15 ` Hyman Rosen 1 sibling, 2 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-17 1:26 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 1:26 ` Marin David Condic @ 2003-10-17 3:59 ` Chad R. Meiners 2003-10-17 11:54 ` Marin David Condic 2003-10-19 22:22 ` Wes Groleau 2003-10-19 1:37 ` Russ 1 sibling, 2 replies; 274+ messages in thread From: Chad R. Meiners @ 2003-10-17 3:59 UTC (permalink / raw) "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. ;-) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 3:59 ` Chad R. Meiners @ 2003-10-17 11:54 ` Marin David Condic 2003-10-17 20:35 ` Russ 2003-10-19 22:22 ` Wes Groleau 1 sibling, 1 reply; 274+ messages in thread From: Marin David Condic @ 2003-10-17 11:54 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 11:54 ` Marin David Condic @ 2003-10-17 20:35 ` Russ 0 siblings, 0 replies; 274+ messages in thread From: Russ @ 2003-10-17 20:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 3:59 ` Chad R. Meiners 2003-10-17 11:54 ` Marin David Condic @ 2003-10-19 22:22 ` Wes Groleau 1 sibling, 0 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-19 22:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 1:26 ` Marin David Condic 2003-10-17 3:59 ` Chad R. Meiners @ 2003-10-19 1:37 ` Russ 2003-10-19 3:16 ` sk ` (6 more replies) 1 sibling, 7 replies; 274+ messages in thread From: Russ @ 2003-10-19 1:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:37 ` Russ @ 2003-10-19 3:16 ` sk 2003-10-19 14:10 ` Preben Randhol ` (5 subsequent siblings) 6 siblings, 0 replies; 274+ messages in thread From: sk @ 2003-10-19 3:16 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:37 ` Russ 2003-10-19 3:16 ` sk @ 2003-10-19 14:10 ` Preben Randhol 2003-10-19 14:29 ` Marin David Condic ` (4 subsequent siblings) 6 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-19 14:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:37 ` Russ 2003-10-19 3:16 ` sk 2003-10-19 14:10 ` Preben Randhol @ 2003-10-19 14:29 ` Marin David Condic 2003-10-20 2:47 ` Russ 2003-10-19 14:40 ` chris ` (3 subsequent siblings) 6 siblings, 1 reply; 274+ messages in thread From: Marin David Condic @ 2003-10-19 14:29 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 14:29 ` Marin David Condic @ 2003-10-20 2:47 ` Russ 2003-10-20 3:03 ` Vinzent 'Gadget' Hoefler ` (3 more replies) 0 siblings, 4 replies; 274+ messages in thread From: Russ @ 2003-10-20 2:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 2:47 ` Russ @ 2003-10-20 3:03 ` Vinzent 'Gadget' Hoefler 2003-10-20 5:47 ` Chad R. Meiners ` (2 subsequent siblings) 3 siblings, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-20 3:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 2:47 ` Russ 2003-10-20 3:03 ` Vinzent 'Gadget' Hoefler @ 2003-10-20 5:47 ` Chad R. Meiners 2003-10-20 12:56 ` Marin David Condic 2003-10-20 6:19 ` Ross Higson 2003-10-20 16:30 ` Martin Dowie 3 siblings, 1 reply; 274+ messages in thread From: Chad R. Meiners @ 2003-10-20 5:47 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 5:47 ` Chad R. Meiners @ 2003-10-20 12:56 ` Marin David Condic 0 siblings, 0 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-20 12:56 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 2:47 ` Russ 2003-10-20 3:03 ` Vinzent 'Gadget' Hoefler 2003-10-20 5:47 ` Chad R. Meiners @ 2003-10-20 6:19 ` Ross Higson 2003-10-21 17:30 ` Russ 2003-10-20 16:30 ` Martin Dowie 3 siblings, 1 reply; 274+ messages in thread From: Ross Higson @ 2003-10-20 6:19 UTC (permalink / raw) > > 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 !) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 6:19 ` Ross Higson @ 2003-10-21 17:30 ` Russ 2003-10-21 18:40 ` sk ` (2 more replies) 0 siblings, 3 replies; 274+ messages in thread From: Russ @ 2003-10-21 17:30 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 17:30 ` Russ @ 2003-10-21 18:40 ` sk 2003-10-22 7:35 ` Russ 2003-10-21 23:28 ` Ross Higson 2003-10-22 7:35 ` Preben Randhol 2 siblings, 1 reply; 274+ messages in thread From: sk @ 2003-10-21 18:40 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 18:40 ` sk @ 2003-10-22 7:35 ` Russ 0 siblings, 0 replies; 274+ messages in thread From: Russ @ 2003-10-22 7:35 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 17:30 ` Russ 2003-10-21 18:40 ` sk @ 2003-10-21 23:28 ` Ross Higson 2003-10-21 23:55 ` Jerry Petrey 2003-10-22 7:35 ` Preben Randhol 2 siblings, 1 reply; 274+ messages in thread From: Ross Higson @ 2003-10-21 23:28 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 23:28 ` Ross Higson @ 2003-10-21 23:55 ` Jerry Petrey 0 siblings, 0 replies; 274+ messages in thread From: Jerry Petrey @ 2003-10-21 23:55 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 17:30 ` Russ 2003-10-21 18:40 ` sk 2003-10-21 23:28 ` Ross Higson @ 2003-10-22 7:35 ` Preben Randhol 2 siblings, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-22 7:35 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 2:47 ` Russ ` (2 preceding siblings ...) 2003-10-20 6:19 ` Ross Higson @ 2003-10-20 16:30 ` Martin Dowie 2003-10-20 17:05 ` Hyman Rosen ` (2 more replies) 3 siblings, 3 replies; 274+ messages in thread From: Martin Dowie @ 2003-10-20 16:30 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 16:30 ` Martin Dowie @ 2003-10-20 17:05 ` Hyman Rosen 2003-10-20 17:46 ` Martin Dowie 2003-10-21 0:57 ` Wes Groleau 2003-10-21 4:49 ` sk 2 siblings, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-20 17:05 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 17:05 ` Hyman Rosen @ 2003-10-20 17:46 ` Martin Dowie 2003-10-20 18:01 ` Hyman Rosen 0 siblings, 1 reply; 274+ messages in thread From: Martin Dowie @ 2003-10-20 17:46 UTC (permalink / raw) "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? :-) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 17:46 ` Martin Dowie @ 2003-10-20 18:01 ` Hyman Rosen 0 siblings, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-20 18:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 16:30 ` Martin Dowie 2003-10-20 17:05 ` Hyman Rosen @ 2003-10-21 0:57 ` Wes Groleau 2003-10-21 1:46 ` Stephane Richard ` (3 more replies) 2003-10-21 4:49 ` sk 2 siblings, 4 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-21 0:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 0:57 ` Wes Groleau @ 2003-10-21 1:46 ` Stephane Richard 2003-10-21 3:38 ` Hyman Rosen ` (2 subsequent siblings) 3 siblings, 0 replies; 274+ messages in thread From: Stephane Richard @ 2003-10-21 1:46 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 0:57 ` Wes Groleau 2003-10-21 1:46 ` Stephane Richard @ 2003-10-21 3:38 ` Hyman Rosen 2003-10-21 8:49 ` Martin Dowie 2003-10-21 9:04 ` Marius Amado Alves 3 siblings, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-21 3:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 0:57 ` Wes Groleau 2003-10-21 1:46 ` Stephane Richard 2003-10-21 3:38 ` Hyman Rosen @ 2003-10-21 8:49 ` Martin Dowie 2003-10-21 9:04 ` Marius Amado Alves 3 siblings, 0 replies; 274+ messages in thread From: Martin Dowie @ 2003-10-21 8:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 0:57 ` Wes Groleau ` (2 preceding siblings ...) 2003-10-21 8:49 ` Martin Dowie @ 2003-10-21 9:04 ` Marius Amado Alves 2003-10-21 13:00 ` Marin David Condic 2003-10-21 13:01 ` Hyman Rosen 3 siblings, 2 replies; 274+ messages in thread From: Marius Amado Alves @ 2003-10-21 9:04 UTC (permalink / raw) To: comp.lang.ada 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 9:04 ` Marius Amado Alves @ 2003-10-21 13:00 ` Marin David Condic 2003-10-21 13:37 ` Marius Amado Alves 2003-10-21 13:01 ` Hyman Rosen 1 sibling, 1 reply; 274+ messages in thread From: Marin David Condic @ 2003-10-21 13:00 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 13:00 ` Marin David Condic @ 2003-10-21 13:37 ` Marius Amado Alves 2003-10-21 14:50 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Marius Amado Alves @ 2003-10-21 13:37 UTC (permalink / raw) To: comp.lang.ada 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 13:37 ` Marius Amado Alves @ 2003-10-21 14:50 ` Robert I. Eachus 2003-10-21 15:01 ` Stephane Richard ` (5 more replies) 0 siblings, 6 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-21 14:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:50 ` Robert I. Eachus @ 2003-10-21 15:01 ` Stephane Richard 2003-10-21 15:03 ` Stephane Richard ` (4 subsequent siblings) 5 siblings, 0 replies; 274+ messages in thread From: Stephane Richard @ 2003-10-21 15:01 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:50 ` Robert I. Eachus 2003-10-21 15:01 ` Stephane Richard @ 2003-10-21 15:03 ` Stephane Richard 2003-10-21 15:07 ` Vinzent 'Gadget' Hoefler ` (3 subsequent siblings) 5 siblings, 0 replies; 274+ messages in thread From: Stephane Richard @ 2003-10-21 15:03 UTC (permalink / raw) [-- 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 > ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:50 ` Robert I. Eachus 2003-10-21 15:01 ` Stephane Richard 2003-10-21 15:03 ` Stephane Richard @ 2003-10-21 15:07 ` Vinzent 'Gadget' Hoefler 2003-10-21 15:13 ` Stephane Richard 2003-10-21 15:58 ` (see below) 2003-10-21 15:24 ` Dmitry A. Kazakov ` (2 subsequent siblings) 5 siblings, 2 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-21 15:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 15:07 ` Vinzent 'Gadget' Hoefler @ 2003-10-21 15:13 ` Stephane Richard 2003-10-21 15:58 ` (see below) 1 sibling, 0 replies; 274+ messages in thread From: Stephane Richard @ 2003-10-21 15:13 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 15:07 ` Vinzent 'Gadget' Hoefler 2003-10-21 15:13 ` Stephane Richard @ 2003-10-21 15:58 ` (see below) 1 sibling, 0 replies; 274+ messages in thread From: (see below) @ 2003-10-21 15:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:50 ` Robert I. Eachus ` (2 preceding siblings ...) 2003-10-21 15:07 ` Vinzent 'Gadget' Hoefler @ 2003-10-21 15:24 ` Dmitry A. Kazakov 2003-10-21 16:44 ` Marius Amado Alves 2003-10-22 7:32 ` Preben Randhol 5 siblings, 0 replies; 274+ messages in thread From: Dmitry A. Kazakov @ 2003-10-21 15:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:50 ` Robert I. Eachus ` (3 preceding siblings ...) 2003-10-21 15:24 ` Dmitry A. Kazakov @ 2003-10-21 16:44 ` Marius Amado Alves 2003-10-22 7:32 ` Preben Randhol 5 siblings, 0 replies; 274+ messages in thread From: Marius Amado Alves @ 2003-10-21 16:44 UTC (permalink / raw) To: comp.lang.ada 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. */ ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 14:50 ` Robert I. Eachus ` (4 preceding siblings ...) 2003-10-21 16:44 ` Marius Amado Alves @ 2003-10-22 7:32 ` Preben Randhol 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler 5 siblings, 1 reply; 274+ messages in thread From: Preben Randhol @ 2003-10-22 7:32 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 7:32 ` Preben Randhol @ 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler 2003-10-22 20:24 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-22 8:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler @ 2003-10-22 20:24 ` Robert I. Eachus 2003-10-27 12:01 ` Vinzent 'Gadget' Hoefler 0 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-22 20:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-22 20:24 ` Robert I. Eachus @ 2003-10-27 12:01 ` Vinzent 'Gadget' Hoefler 2003-10-27 17:31 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-27 12:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-27 12:01 ` Vinzent 'Gadget' Hoefler @ 2003-10-27 17:31 ` Robert I. Eachus 0 siblings, 0 replies; 274+ messages in thread From: Robert I. Eachus @ 2003-10-27 17:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 9:04 ` Marius Amado Alves 2003-10-21 13:00 ` Marin David Condic @ 2003-10-21 13:01 ` Hyman Rosen 1 sibling, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-21 13:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 16:30 ` Martin Dowie 2003-10-20 17:05 ` Hyman Rosen 2003-10-21 0:57 ` Wes Groleau @ 2003-10-21 4:49 ` sk 2003-10-21 21:19 ` Simon Wright 2 siblings, 1 reply; 274+ messages in thread From: sk @ 2003-10-21 4:49 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 4:49 ` sk @ 2003-10-21 21:19 ` Simon Wright 2003-10-22 4:37 ` sk 0 siblings, 1 reply; 274+ messages in thread From: Simon Wright @ 2003-10-21 21:19 UTC (permalink / raw) 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 .. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 21:19 ` Simon Wright @ 2003-10-22 4:37 ` sk 0 siblings, 0 replies; 274+ messages in thread From: sk @ 2003-10-22 4:37 UTC (permalink / raw) To: comp.lang.ada 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 ------------------------------------------------- ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:37 ` Russ ` (2 preceding siblings ...) 2003-10-19 14:29 ` Marin David Condic @ 2003-10-19 14:40 ` chris 2003-10-19 15:12 ` Stephane Richard ` (2 subsequent siblings) 6 siblings, 0 replies; 274+ messages in thread From: chris @ 2003-10-19 14:40 UTC (permalink / raw) 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! ;) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:37 ` Russ ` (3 preceding siblings ...) 2003-10-19 14:40 ` chris @ 2003-10-19 15:12 ` Stephane Richard 2003-10-19 16:26 ` Robert I. Eachus 2003-10-19 21:09 ` Dmytry Lavrov 6 siblings, 0 replies; 274+ messages in thread From: Stephane Richard @ 2003-10-19 15:12 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:37 ` Russ ` (4 preceding siblings ...) 2003-10-19 15:12 ` Stephane Richard @ 2003-10-19 16:26 ` Robert I. Eachus 2003-10-20 2:02 ` Hyman Rosen 2003-10-19 21:09 ` Dmytry Lavrov 6 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-19 16:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 16:26 ` Robert I. Eachus @ 2003-10-20 2:02 ` Hyman Rosen 2003-10-20 6:12 ` Robert I. Eachus 0 siblings, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-20 2:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 2:02 ` Hyman Rosen @ 2003-10-20 6:12 ` Robert I. Eachus 2003-10-20 12:50 ` Hyman Rosen 0 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-20 6:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 6:12 ` Robert I. Eachus @ 2003-10-20 12:50 ` Hyman Rosen 2003-10-20 17:53 ` Robert I. Eachus 2003-10-21 3:05 ` Alexandre E. Kopilovitch 0 siblings, 2 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-20 12:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 12:50 ` Hyman Rosen @ 2003-10-20 17:53 ` Robert I. Eachus 2003-10-20 18:03 ` Hyman Rosen 2003-10-21 3:05 ` Alexandre E. Kopilovitch 1 sibling, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-20 17:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 17:53 ` Robert I. Eachus @ 2003-10-20 18:03 ` Hyman Rosen 2003-10-21 1:35 ` Marin David Condic 0 siblings, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-20 18:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 18:03 ` Hyman Rosen @ 2003-10-21 1:35 ` Marin David Condic 0 siblings, 0 replies; 274+ messages in thread From: Marin David Condic @ 2003-10-21 1:35 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 12:50 ` Hyman Rosen 2003-10-20 17:53 ` Robert I. Eachus @ 2003-10-21 3:05 ` Alexandre E. Kopilovitch 2003-10-21 3:30 ` Hyman Rosen 1 sibling, 1 reply; 274+ messages in thread From: Alexandre E. Kopilovitch @ 2003-10-21 3:05 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 3:05 ` Alexandre E. Kopilovitch @ 2003-10-21 3:30 ` Hyman Rosen 2003-10-21 13:22 ` Alexandre E. Kopilovitch 0 siblings, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-21 3:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 3:30 ` Hyman Rosen @ 2003-10-21 13:22 ` Alexandre E. Kopilovitch 2003-10-21 15:02 ` Hyman Rosen 0 siblings, 1 reply; 274+ messages in thread From: Alexandre E. Kopilovitch @ 2003-10-21 13:22 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-21 13:22 ` Alexandre E. Kopilovitch @ 2003-10-21 15:02 ` Hyman Rosen 0 siblings, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-21 15:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-19 1:37 ` Russ ` (5 preceding siblings ...) 2003-10-19 16:26 ` Robert I. Eachus @ 2003-10-19 21:09 ` Dmytry Lavrov 6 siblings, 0 replies; 274+ messages in thread From: Dmytry Lavrov @ 2003-10-19 21:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 0:26 ` Robert I. Eachus 2003-10-17 1:26 ` Marin David Condic @ 2003-10-17 14:15 ` Hyman Rosen 2003-10-17 14:40 ` Lutz Donnerhacke ` (2 more replies) 1 sibling, 3 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-17 14:15 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 14:15 ` Hyman Rosen @ 2003-10-17 14:40 ` Lutz Donnerhacke 2003-10-17 15:40 ` Hyman Rosen 2003-10-18 0:08 ` Russ 2003-10-20 5:35 ` Chad R. Meiners 2 siblings, 1 reply; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-17 14:40 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 14:40 ` Lutz Donnerhacke @ 2003-10-17 15:40 ` Hyman Rosen 2003-10-17 15:49 ` Lutz Donnerhacke 2003-10-17 16:02 ` Preben Randhol 0 siblings, 2 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-17 15:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 15:40 ` Hyman Rosen @ 2003-10-17 15:49 ` Lutz Donnerhacke 2003-10-17 20:43 ` Hyman Rosen 2003-10-17 16:02 ` Preben Randhol 1 sibling, 1 reply; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-17 15:49 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 15:49 ` Lutz Donnerhacke @ 2003-10-17 20:43 ` Hyman Rosen 0 siblings, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-17 20:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 15:40 ` Hyman Rosen 2003-10-17 15:49 ` Lutz Donnerhacke @ 2003-10-17 16:02 ` Preben Randhol 2003-10-17 16:06 ` Preben Randhol 2003-10-19 22:36 ` Wes Groleau 1 sibling, 2 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-17 16:02 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 16:02 ` Preben Randhol @ 2003-10-17 16:06 ` Preben Randhol 2003-10-19 22:36 ` Wes Groleau 1 sibling, 0 replies; 274+ messages in thread From: Preben Randhol @ 2003-10-17 16:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 16:02 ` Preben Randhol 2003-10-17 16:06 ` Preben Randhol @ 2003-10-19 22:36 ` Wes Groleau 1 sibling, 0 replies; 274+ messages in thread From: Wes Groleau @ 2003-10-19 22:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 14:15 ` Hyman Rosen 2003-10-17 14:40 ` Lutz Donnerhacke @ 2003-10-18 0:08 ` Russ 2003-10-18 10:31 ` Georg Bauhaus 2003-10-20 5:35 ` Chad R. Meiners 2 siblings, 1 reply; 274+ messages in thread From: Russ @ 2003-10-18 0:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-18 0:08 ` Russ @ 2003-10-18 10:31 ` Georg Bauhaus 0 siblings, 0 replies; 274+ messages in thread From: Georg Bauhaus @ 2003-10-18 10:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 14:15 ` Hyman Rosen 2003-10-17 14:40 ` Lutz Donnerhacke 2003-10-18 0:08 ` Russ @ 2003-10-20 5:35 ` Chad R. Meiners 2003-10-20 13:00 ` Hyman Rosen 2 siblings, 1 reply; 274+ messages in thread From: Chad R. Meiners @ 2003-10-20 5:35 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 5:35 ` Chad R. Meiners @ 2003-10-20 13:00 ` Hyman Rosen 2003-10-20 14:27 ` (see below) 0 siblings, 1 reply; 274+ messages in thread From: Hyman Rosen @ 2003-10-20 13:00 UTC (permalink / raw) 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 --. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 13:00 ` Hyman Rosen @ 2003-10-20 14:27 ` (see below) 2003-10-20 15:58 ` Chad R. Meiners 0 siblings, 1 reply; 274+ messages in thread From: (see below) @ 2003-10-20 14:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-20 14:27 ` (see below) @ 2003-10-20 15:58 ` Chad R. Meiners 0 siblings, 0 replies; 274+ messages in thread From: Chad R. Meiners @ 2003-10-20 15:58 UTC (permalink / raw) "(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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 15:42 ` Mark A. Biggar 2003-10-16 16:48 ` Hyman Rosen @ 2003-10-16 21:53 ` Russ 1 sibling, 0 replies; 274+ messages in thread From: Russ @ 2003-10-16 21:53 UTC (permalink / raw) "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). ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-16 13:46 ` Hyman Rosen 2003-10-16 15:42 ` Mark A. Biggar @ 2003-10-17 8:20 ` Lutz Donnerhacke 2003-10-17 14:21 ` Hyman Rosen 1 sibling, 1 reply; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-17 8:20 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 8:20 ` Lutz Donnerhacke @ 2003-10-17 14:21 ` Hyman Rosen 2003-10-17 14:42 ` Lutz Donnerhacke ` (2 more replies) 0 siblings, 3 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-17 14:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 14:21 ` Hyman Rosen @ 2003-10-17 14:42 ` Lutz Donnerhacke 2003-10-17 15:46 ` Hyman Rosen 2003-10-17 15:35 ` Larry Kilgallen 2003-10-17 16:02 ` Robert I. Eachus 2 siblings, 1 reply; 274+ messages in thread From: Lutz Donnerhacke @ 2003-10-17 14:42 UTC (permalink / raw) * 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++". ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 14:42 ` Lutz Donnerhacke @ 2003-10-17 15:46 ` Hyman Rosen 0 siblings, 0 replies; 274+ messages in thread From: Hyman Rosen @ 2003-10-17 15:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 14:21 ` Hyman Rosen 2003-10-17 14:42 ` Lutz Donnerhacke @ 2003-10-17 15:35 ` Larry Kilgallen 2003-10-17 16:02 ` Robert I. Eachus 2 siblings, 0 replies; 274+ messages in thread From: Larry Kilgallen @ 2003-10-17 15:35 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 14:21 ` Hyman Rosen 2003-10-17 14:42 ` Lutz Donnerhacke 2003-10-17 15:35 ` Larry Kilgallen @ 2003-10-17 16:02 ` Robert I. Eachus 2003-10-17 17:20 ` Chad R. Meiners 2 siblings, 1 reply; 274+ messages in thread From: Robert I. Eachus @ 2003-10-17 16:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-17 16:02 ` Robert I. Eachus @ 2003-10-17 17:20 ` Chad R. Meiners 0 siblings, 0 replies; 274+ messages in thread From: Chad R. Meiners @ 2003-10-17 17:20 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: += in ada 2003-10-14 9:52 ` += in ada Stuart Palin 2003-10-16 8:49 ` Russ @ 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler 1 sibling, 0 replies; 274+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2003-10-16 8:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 274+ messages in thread
[parent not found: <mailman.180.1066854383.25614.comp.lang.ada@ada-france.org>]
* Re: Early Ada Mistakes (was: Re: += in ada) [not found] <mailman.180.1066854383.25614.comp.lang.ada@ada-france.org> @ 2003-10-22 20:58 ` Ed Falis 0 siblings, 0 replies; 274+ messages in thread From: Ed Falis @ 2003-10-22 20:58 UTC (permalink / raw) On Wed, 22 Oct 2003 16:25:44 -0400, Beard, Frank Randolph CIV <frank.beard@navy.mil> wrote: > I believe they were bought out by IBM. We were using their compiler > on the IBM Mainframe for Space Station. If you ever wondered how to > make compiler messages more obscure, compile on MVS. > Telesoft was bought by Alsys after the latter was bought by Thomson. The remnants of the original Telesoft development group are still part of Aonix, I think (though I wouldn't swear it). - Ed ^ permalink raw reply [flat|nested] 274+ messages in thread
[parent not found: <mailman.181.1066858869.25614.comp.lang.ada@ada-france.org>]
* Re: Early Ada Mistakes (was: Re: += in ada) [not found] <mailman.181.1066858869.25614.comp.lang.ada@ada-france.org> @ 2003-10-22 21:49 ` Ed Falis 2003-10-23 3:21 ` Alexandre E. Kopilovitch 2003-10-23 7:15 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 274+ messages in thread From: Ed Falis @ 2003-10-22 21:49 UTC (permalink / raw) On Wed, 22 Oct 2003 17:39:56 -0400, Beard, Frank Randolph CIV <frank.beard@navy.mil> wrote: > I thought that was TeleUSE, not TeleSoft, but you would know better than > me. Sorry for the misinformation. At least, I'm pretty sure it was the > TeleSoft compiler we used on the IBM Mainframe. Oh, it's easy to get confused - I'm still confused about why the orignal Alsys US office was shut down. But's that's the software industry, eh? Someone should write a biography of Ada along the lines of "Soul of a New Machine". All of the dramatic elements are there for the general entertainment. - Ed ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes (was: Re: += in ada) 2003-10-22 21:49 ` Ed Falis @ 2003-10-23 3:21 ` Alexandre E. Kopilovitch 2003-10-23 7:15 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 274+ messages in thread From: Alexandre E. Kopilovitch @ 2003-10-23 3:21 UTC (permalink / raw) To: comp.lang.ada Ed Falis wrote: >Someone should write a biography of Ada along the lines of "Soul of a New >Machine". All of the dramatic elements are there for the general >entertainment. I have read "Soul of a New Machine" about 15 years ago, and I still remember it. And I don't think that it is possible to compose something similar about Ada, because a problem of hardware (in broad sense, it shouldn't be necessarily computers). Hardware must be in place, you can't produce really good literature about software only... because that software must have a valid purpose (without known purpose all software-related problems will look just as a kind of soap opera). And I think that this is particularly true for Ada. So, if you include both Ada and hardware, you'll get not a small book, but a huge volume. Then, look at the characters: those in "Soul..." are good persons, but even the main character is still not heavyweight - and what we have in Ada history in this respect? Although... if you ask Tim Rice, perhaps he will find it an interesting idea? -:) Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia Ed Falis wrote: >Someone should write a biography of Ada along the lines of "Soul of a New >Machine". All of the dramatic elements are there for the general >entertainment. I have read "Soul of a New Machine" about 15 years ago, and I still remember it. And I don't think that it is possible to compose something similar about Ada, because a problem of hardware (in broad sense, it shouldn't be necessarily computers). Hardware must be in place, you can't produce really good literature about software only... because that software must have a valid purpose (without known purpose all software-related problems will look just as a kind of soap opera). And I think that this is particularly true for Ada. So, if you include both Ada and hardware, you'll get not a small book, but a huge volume. Then, look at the characters: those in "Soul..." are good persons, but even the main character is still not heavyweight - and what we have in Ada history in this respect? Although... if you ask Tim Rice, perhaps he will find it an interesting idea? -:) Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 274+ messages in thread
* Re: Early Ada Mistakes (was: Re: += in ada) 2003-10-22 21:49 ` Ed Falis 2003-10-23 3:21 ` Alexandre E. Kopilovitch @ 2003-10-23 7:15 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 274+ messages in thread From: Ole-Hjalmar Kristensen @ 2003-10-23 7:15 UTC (permalink / raw) >>>>> "EF" == Ed Falis <falis@verizon.net> writes: EF> On Wed, 22 Oct 2003 17:39:56 -0400, Beard, Frank Randolph CIV EF> <frank.beard@navy.mil> wrote: >> I thought that was TeleUSE, not TeleSoft, but you would know better than >> me. Sorry for the misinformation. At least, I'm pretty sure it was the >> TeleSoft compiler we used on the IBM Mainframe. EF> Oh, it's easy to get confused - I'm still confused about why the EF> orignal Alsys US office was shut down. But's that's the software EF> industry, eh? EF> Someone should write a biography of Ada along the lines of "Soul of a EF> New Machine". All of the dramatic elements are there for the general EF> entertainment. EF> - Ed If I remember correctly, both the TeleSoft compiler and the TeleUse UIMS came from the same company (TeleSoft). -- This page intentionally left blank ^ permalink raw reply [flat|nested] 274+ messages in thread
end of thread, other threads:[~2003-10-31 22:40 UTC | newest] Thread overview: 274+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-25 16:25 += in ada Dmytry Lavrov 2003-10-01 8:35 ` Peter Amey 2003-10-01 12:38 ` Frank J. Lhota 2003-10-03 16:22 ` Isaac Gouy 2003-10-06 20:21 ` Russ 2003-10-06 22:47 ` (see below) 2003-10-04 20:17 ` Craig Carey 2003-10-06 7:36 ` Jean-Pierre Rosen 2003-10-06 8:13 ` Lutz Donnerhacke 2003-10-06 22:49 ` Wes Groleau 2003-10-01 14:06 ` Gautier 2003-10-02 12:26 ` Lutz Donnerhacke 2003-10-02 13:03 ` Preben Randhol 2003-10-02 13:36 ` Lutz Donnerhacke 2003-10-02 21:28 ` Keith Thompson 2003-10-07 0:41 ` Russ 2003-10-07 10:05 ` Dmytry Lavrov 2003-10-07 11:56 ` Lutz Donnerhacke 2003-10-07 14:02 ` (see below) 2003-10-07 22:22 ` Russ 2003-10-07 23:52 ` (see below) 2003-10-08 6:08 ` Preben Randhol 2003-10-09 19:07 ` Russ 2003-10-09 19:42 ` Vinzent 'Gadget' Hoefler [not found] ` <25oh51-uu2.ln1@beastie.ix.netcom.com> 2003-10-10 7:37 ` Preben Randhol 2003-10-10 18:56 ` Russ 2003-10-11 8:10 ` Preben Randhol 2003-10-11 8:30 ` Samuel Tardieu 2003-10-10 12:09 ` Vinzent 'Gadget' Hoefler 2003-10-10 7:34 ` Preben Randhol 2003-10-12 0:50 ` Wes Groleau 2003-10-12 8:24 ` Preben Randhol 2003-10-12 14:57 ` Robert I. Eachus 2003-10-12 18:37 ` (see below) 2003-10-13 0:42 ` Robert I. Eachus 2003-10-13 8:32 ` Dmytry Lavrov 2003-10-13 19:18 ` Robert I. Eachus 2003-10-13 23:36 ` Alexandre E. Kopilovitch 2003-10-14 6:14 ` Vinzent 'Gadget' Hoefler 2003-10-14 15:19 ` Robert I. Eachus 2003-10-30 21:43 ` ARG process (was += in ada) Randy Brukardt 2003-10-30 23:21 ` Robert I. Eachus 2003-10-10 20:31 ` += in ada Dmytry Lavrov 2003-10-12 8:23 ` Dmytry Lavrov 2003-10-14 18:00 ` Russ 2003-10-14 18:15 ` Vinzent 'Gadget' Hoefler 2003-10-15 12:50 ` Georg Bauhaus 2003-10-15 13:25 ` Hyman Rosen 2003-10-15 14:04 ` Vinzent 'Gadget' Hoefler 2003-10-15 15:19 ` Hyman Rosen 2003-10-15 18:06 ` Vinzent 'Gadget' Hoefler 2003-10-15 18:53 ` Hyman Rosen 2003-10-15 19:34 ` Vinzent 'Gadget' Hoefler 2003-10-15 23:09 ` Alexandre E. Kopilovitch 2003-10-16 5:05 ` Russ 2003-10-16 12:07 ` Marin David Condic 2003-10-16 13:43 ` Hyman Rosen 2003-10-16 23:57 ` Robert I. Eachus 2003-10-17 6:22 ` Russ 2003-10-17 6:38 ` Preben Randhol 2003-10-17 15:48 ` Robert I. Eachus 2003-10-19 1:15 ` Russ 2003-10-19 16:04 ` Robert I. Eachus 2003-10-19 23:59 ` Russ 2003-10-20 5:24 ` Chad R. Meiners 2003-10-20 5:52 ` Robert I. Eachus 2003-10-20 12:40 ` Marin David Condic 2003-10-20 14:36 ` Preben Randhol 2003-10-21 0:23 ` Wes Groleau 2003-10-21 3:46 ` Hyman Rosen 2003-10-21 6:37 ` Russ 2003-10-21 10:10 ` Marius Amado Alves 2003-10-22 5:23 ` Russ 2003-10-20 14:34 ` Preben Randhol 2003-10-21 7:43 ` Russ 2003-10-21 12:45 ` Lutz Donnerhacke 2003-10-22 7:13 ` Russ 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler 2003-10-22 9:02 ` Lutz Donnerhacke 2003-10-22 18:21 ` Russ 2003-10-22 19:10 ` Vinzent 'Gadget' Hoefler 2003-10-23 5:24 ` + " Russ 2003-10-22 19:16 ` += " sk 2003-10-22 19:13 ` Vinzent 'Gadget' Hoefler 2003-10-23 5:16 ` Russ 2003-10-23 5:45 ` sk 2003-10-22 21:22 ` Russ 2003-10-23 2:23 ` Wes Groleau 2003-10-22 9:46 ` Preben Randhol 2003-10-22 8:01 ` Russ 2003-10-21 13:38 ` Robert I. Eachus 2003-10-22 7:24 ` Russ 2003-10-22 19:50 ` Robert I. Eachus 2003-10-23 5:34 ` Russ 2003-10-23 14:14 ` Robert I. Eachus 2003-10-24 9:15 ` Peter Hermann 2003-10-24 10:11 ` Marius Amado Alves 2003-10-26 7:35 ` Pascal Obry 2003-10-24 11:20 ` Marin David Condic 2003-10-25 3:14 ` Russ 2003-10-25 5:07 ` Russ 2003-10-19 23:19 ` Robert A Duff 2003-10-20 6:16 ` Russ 2003-10-20 14:31 ` Preben Randhol 2003-10-20 17:10 ` Robert I. Eachus 2003-10-20 17:53 ` Hyman Rosen 2003-10-20 19:11 ` Robert I. Eachus 2003-10-20 19:32 ` Hyman Rosen 2003-10-20 23:24 ` Alexandre E. Kopilovitch 2003-10-21 0:40 ` Wes Groleau 2003-10-21 3:45 ` Hyman Rosen 2003-10-21 12:07 ` Preben Randhol 2003-10-21 12:18 ` Marius Amado Alves 2003-10-21 12:45 ` Marin David Condic 2003-10-21 14:46 ` Robert I. Eachus 2003-10-21 17:54 ` Chad R. Meiners 2003-10-21 20:23 ` Robert I. Eachus 2003-10-22 0:18 ` Wes Groleau 2003-10-22 4:07 ` Robert I. Eachus 2003-10-22 20:41 ` Wes Groleau 2003-10-22 11:56 ` Marin David Condic 2003-10-22 0:14 ` Wes Groleau 2003-10-22 12:31 ` Early Ada Mistakes (was: Re: += in ada) Marin David Condic 2003-10-22 20:05 ` Robert I. Eachus 2003-10-23 4:47 ` Marin David Condic 2003-10-23 14:36 ` Early Ada Mistakes Hyman Rosen 2003-10-23 19:04 ` Chad R. Meiners 2003-10-24 13:33 ` Preben Randhol 2003-10-24 16:59 ` Robert I. Eachus 2003-10-23 19:08 ` Wes Groleau 2003-10-23 22:17 ` Robert I. Eachus 2003-10-24 11:26 ` Marin David Condic 2003-10-23 18:50 ` Wes Groleau 2003-10-22 21:00 ` Wes Groleau 2003-10-23 4:53 ` Marin David Condic 2003-10-22 6:56 ` += in ada Russ 2003-10-22 7:26 ` Preben Randhol 2003-10-22 11:27 ` Stephane Richard 2003-10-22 20:12 ` Robert I. Eachus 2003-10-22 20:52 ` Wes Groleau [not found] ` <emte61-d03.ln1@beastie.ix.netcom.com> 2003-10-21 12:57 ` Hyman Rosen 2003-10-21 2:43 ` Alexandre E. Kopilovitch 2003-10-21 9:39 ` Stephane Richard 2003-10-19 22:26 ` Wes Groleau 2003-10-16 4:31 ` + " Russ 2003-10-16 8:57 ` += " Vinzent 'Gadget' Hoefler 2003-10-16 20:56 ` + " Georg Bauhaus 2003-10-16 4:04 ` += " Russ 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler 2003-10-17 3:03 ` Wes Groleau 2003-10-17 11:46 ` Marin David Condic 2003-10-17 11:50 ` Preben Randhol 2003-10-17 12:40 ` sk 2003-10-17 12:48 ` Preben Randhol 2003-10-15 14:16 ` Dmytry Lavrov 2003-10-16 5:40 ` Russ 2003-10-16 12:45 ` Lutz Donnerhacke 2003-10-16 22:07 ` Russ 2003-10-17 9:10 ` Lutz Donnerhacke 2003-10-16 13:48 ` Dmytry Lavrov 2003-10-16 20:46 ` Georg Bauhaus 2003-10-17 2:37 ` Russ 2003-10-17 3:01 ` sk 2003-10-17 5:42 ` Russ 2003-10-17 11:26 ` sk 2003-10-17 20:24 ` Dmytry Lavrov 2003-10-17 3:52 ` Chad R. Meiners 2003-10-17 6:32 ` Preben Randhol 2003-10-17 8:48 ` Dmytry Lavrov 2003-10-16 1:25 ` Chad R. Meiners 2003-10-19 23:50 ` Robert A Duff 2003-10-20 5:52 ` Chad R. Meiners 2003-10-07 18:28 ` Alexander Kopilovitch 2003-10-10 19:56 ` Dmytry Lavrov 2003-10-20 7:41 ` idem (Was: += in ada) Jacob Sparre Andersen 2003-10-20 8:28 ` Dmitry A. Kazakov 2003-10-20 8:34 ` (see below) 2003-10-31 22:40 ` Nick Roberts 2003-10-14 9:52 ` += in ada Stuart Palin 2003-10-16 8:49 ` Russ 2003-10-16 12:46 ` Lutz Donnerhacke 2003-10-16 13:46 ` Hyman Rosen 2003-10-16 15:42 ` Mark A. Biggar 2003-10-16 16:48 ` Hyman Rosen 2003-10-17 0:26 ` Robert I. Eachus 2003-10-17 1:26 ` Marin David Condic 2003-10-17 3:59 ` Chad R. Meiners 2003-10-17 11:54 ` Marin David Condic 2003-10-17 20:35 ` Russ 2003-10-19 22:22 ` Wes Groleau 2003-10-19 1:37 ` Russ 2003-10-19 3:16 ` sk 2003-10-19 14:10 ` Preben Randhol 2003-10-19 14:29 ` Marin David Condic 2003-10-20 2:47 ` Russ 2003-10-20 3:03 ` Vinzent 'Gadget' Hoefler 2003-10-20 5:47 ` Chad R. Meiners 2003-10-20 12:56 ` Marin David Condic 2003-10-20 6:19 ` Ross Higson 2003-10-21 17:30 ` Russ 2003-10-21 18:40 ` sk 2003-10-22 7:35 ` Russ 2003-10-21 23:28 ` Ross Higson 2003-10-21 23:55 ` Jerry Petrey 2003-10-22 7:35 ` Preben Randhol 2003-10-20 16:30 ` Martin Dowie 2003-10-20 17:05 ` Hyman Rosen 2003-10-20 17:46 ` Martin Dowie 2003-10-20 18:01 ` Hyman Rosen 2003-10-21 0:57 ` Wes Groleau 2003-10-21 1:46 ` Stephane Richard 2003-10-21 3:38 ` Hyman Rosen 2003-10-21 8:49 ` Martin Dowie 2003-10-21 9:04 ` Marius Amado Alves 2003-10-21 13:00 ` Marin David Condic 2003-10-21 13:37 ` Marius Amado Alves 2003-10-21 14:50 ` Robert I. Eachus 2003-10-21 15:01 ` Stephane Richard 2003-10-21 15:03 ` Stephane Richard 2003-10-21 15:07 ` Vinzent 'Gadget' Hoefler 2003-10-21 15:13 ` Stephane Richard 2003-10-21 15:58 ` (see below) 2003-10-21 15:24 ` Dmitry A. Kazakov 2003-10-21 16:44 ` Marius Amado Alves 2003-10-22 7:32 ` Preben Randhol 2003-10-22 8:48 ` Vinzent 'Gadget' Hoefler 2003-10-22 20:24 ` Robert I. Eachus 2003-10-27 12:01 ` Vinzent 'Gadget' Hoefler 2003-10-27 17:31 ` Robert I. Eachus 2003-10-21 13:01 ` Hyman Rosen 2003-10-21 4:49 ` sk 2003-10-21 21:19 ` Simon Wright 2003-10-22 4:37 ` sk 2003-10-19 14:40 ` chris 2003-10-19 15:12 ` Stephane Richard 2003-10-19 16:26 ` Robert I. Eachus 2003-10-20 2:02 ` Hyman Rosen 2003-10-20 6:12 ` Robert I. Eachus 2003-10-20 12:50 ` Hyman Rosen 2003-10-20 17:53 ` Robert I. Eachus 2003-10-20 18:03 ` Hyman Rosen 2003-10-21 1:35 ` Marin David Condic 2003-10-21 3:05 ` Alexandre E. Kopilovitch 2003-10-21 3:30 ` Hyman Rosen 2003-10-21 13:22 ` Alexandre E. Kopilovitch 2003-10-21 15:02 ` Hyman Rosen 2003-10-19 21:09 ` Dmytry Lavrov 2003-10-17 14:15 ` Hyman Rosen 2003-10-17 14:40 ` Lutz Donnerhacke 2003-10-17 15:40 ` Hyman Rosen 2003-10-17 15:49 ` Lutz Donnerhacke 2003-10-17 20:43 ` Hyman Rosen 2003-10-17 16:02 ` Preben Randhol 2003-10-17 16:06 ` Preben Randhol 2003-10-19 22:36 ` Wes Groleau 2003-10-18 0:08 ` Russ 2003-10-18 10:31 ` Georg Bauhaus 2003-10-20 5:35 ` Chad R. Meiners 2003-10-20 13:00 ` Hyman Rosen 2003-10-20 14:27 ` (see below) 2003-10-20 15:58 ` Chad R. Meiners 2003-10-16 21:53 ` Russ 2003-10-17 8:20 ` Lutz Donnerhacke 2003-10-17 14:21 ` Hyman Rosen 2003-10-17 14:42 ` Lutz Donnerhacke 2003-10-17 15:46 ` Hyman Rosen 2003-10-17 15:35 ` Larry Kilgallen 2003-10-17 16:02 ` Robert I. Eachus 2003-10-17 17:20 ` Chad R. Meiners 2003-10-16 8:57 ` Vinzent 'Gadget' Hoefler [not found] <mailman.180.1066854383.25614.comp.lang.ada@ada-france.org> 2003-10-22 20:58 ` Early Ada Mistakes (was: Re: += in ada) Ed Falis [not found] <mailman.181.1066858869.25614.comp.lang.ada@ada-france.org> 2003-10-22 21:49 ` Ed Falis 2003-10-23 3:21 ` Alexandre E. Kopilovitch 2003-10-23 7:15 ` Ole-Hjalmar Kristensen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox