* C like op= proposal @ 1999-08-15 0:00 Brian Rogoff 1999-08-15 0:00 ` Ray Blaak 1999-08-16 0:00 ` Robert Dewar 0 siblings, 2 replies; 33+ messages in thread From: Brian Rogoff @ 1999-08-15 0:00 UTC (permalink / raw) A few weeks ago the topic of the readability of C's op= construct vis-a-vis the Ada "lhs := lhs op operand;" statements, with the general tenor being that the C syntax is more readable, at least in cases where "lhs" is some fairly long identifier, perhaps an array embedded in a record being incremented or otherwise operated upon. I remembered reading about a language which had a more general approach to this, allowing a pseudo-variable, say "@" to represent the old value of the left hand side of an assignment in the right hand side, thus allowing things like lhs := @ + 1; -- C: lhs++; lhs := @ * 5; -- C: lhs *= 5; lhs := 1/@ + 5*(@/2 + @ ** 2); -- C doesn't do so good here either! Was anything like this ever discussed for Ada? Assuming some acceptable notation was chosen for the pseudo-variable ("_" works, but stands out less to my eye than "@"), would people find this more or less readable than the current verbose approach? -- Brian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-15 0:00 C like op= proposal Brian Rogoff @ 1999-08-15 0:00 ` Ray Blaak 1999-08-15 0:00 ` Brian Rogoff 1999-08-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 33+ messages in thread From: Ray Blaak @ 1999-08-15 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > lhs := @ + 1; -- C: lhs++; > lhs := @ * 5; -- C: lhs *= 5; > lhs := 1/@ + 5*(@/2 + @ ** 2); -- C doesn't do so good here either! This is not worth the trouble of changing the language, especially considering that one can already do this: declare lhs : Some_Type renames Long_And_Complicated_Lvalue; begin lhs := lhs + 1; -- C: lhs++; lhs := lhs * 5; -- C: lhs *= 5; lhs := 1/lhs + 5*(lhs/2 + lhs ** 2); -- C doesn't do so good here either! end; -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-15 0:00 ` Ray Blaak @ 1999-08-15 0:00 ` Brian Rogoff 1999-08-16 0:00 ` Gautier 0 siblings, 1 reply; 33+ messages in thread From: Brian Rogoff @ 1999-08-15 0:00 UTC (permalink / raw) On 15 Aug 1999, Ray Blaak wrote: > Brian Rogoff <bpr@shell5.ba.best.com> writes: > > lhs := @ + 1; -- C: lhs++; > > lhs := @ * 5; -- C: lhs *= 5; > > lhs := 1/@ + 5*(@/2 + @ ** 2); -- C doesn't do so good here either! > > This is not worth the trouble of changing the language, especially considering > that one can already do this: > > declare > lhs : Some_Type renames Long_And_Complicated_Lvalue; > begin > lhs := lhs + 1; -- C: lhs++; > lhs := lhs * 5; -- C: lhs *= 5; > lhs := 1/lhs + 5*(lhs/2 + lhs ** 2); -- C doesn't do so good here either! > end; Well, that won't work for the case I described, in which lhs is or contains an array being indexed, unless you rename each occurrence every time through the loop. But I guess that would be the correct Ada approach. Seems awfully heavyweight compared to the C approach and what I sketched. It's certainly not any more than syntactic sugar, but if I were designing my own Ada like language from scratch, would it be worth including such a facility? -- Brian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-15 0:00 ` Brian Rogoff @ 1999-08-16 0:00 ` Gautier 1999-08-17 0:00 ` Samuel Tardieu 1999-08-17 0:00 ` John Duncan 0 siblings, 2 replies; 33+ messages in thread From: Gautier @ 1999-08-16 0:00 UTC (permalink / raw) > It's certainly not any more than syntactic sugar, but if I were designing > my own Ada like language from scratch, would it be worth including > such a facility? Into the language I think it would be an overload. But there are situation where there is not a:= a + 1; or a:= a + b; which is at the same time more readble than the "++"s macro-assembler counterparts _and_ transformed into "++"s by optimizers, _but_ a(b(c,d+e(f,g)).h(i,j)) := a(b(c,d+e(f,g)).h(i,j)) + 1; which can be horribily long and unlikely to be catched by the optimizer -> 2x too slow (at least: the extra code makes a penalty for processor cache). I these cases there are some solutions: - A "renames". But you have to make a declare..begin..end block each time :-( - Inlined procedures "Inc", "Add" etc. This is much better... Both solutions may produce code near to a "a(b(c,d+e(f,g)).h(i,j))++" but it has to be verified. I'm using a generic Add_Inc package - but I'm sure that a standard Ada.* equivalent with "intrinsic" pragmas would be the best solution! generic type pm_elt is private; one: pm_elt; with function "+" (left,right:pm_elt) return pm_elt is <>; with function "-" (left,right:pm_elt) return pm_elt is <>; package Add_Inc is procedure Add(a:in out pm_elt; b:pm_elt); procedure Sub(a:in out pm_elt; b:pm_elt); procedure Inc(a:in out pm_elt); procedure Dec(a:in out pm_elt); end; package body Add_Inc is procedure Add(a:in out pm_elt; b:pm_elt) is begin a:= a+b; end; procedure Sub(a:in out pm_elt; b:pm_elt) is begin a:= a-b; end; procedure Inc(a:in out pm_elt) is begin a:=a+one; end; procedure Dec(a:in out pm_elt) is begin a:=a-one; end; pragma Inline(Add,Sub,Inc,Dec); end; -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-16 0:00 ` Gautier @ 1999-08-17 0:00 ` Samuel Tardieu 1999-08-17 0:00 ` Gautier ` (2 more replies) 1999-08-17 0:00 ` John Duncan 1 sibling, 3 replies; 33+ messages in thread From: Samuel Tardieu @ 1999-08-17 0:00 UTC (permalink / raw) To: Gautier >>>>> "Gautier" == Gautier <Gautier.deMontmollin@Maths.UniNe.CH> writes: Gautier> a(b(c,d+e(f,g)).h(i,j)) := a(b(c,d+e(f,g)).h(i,j)) + 1; Gautier> which can be horribily long and unlikely to be catched by the Gautier> optimizer -> 2x too slow (at least: the extra code makes a Gautier> penalty for processor cache). 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; ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-17 0:00 ` Samuel Tardieu @ 1999-08-17 0:00 ` Gautier 1999-08-17 0:00 ` Andi Kleen 1999-08-18 0:00 ` Gautier 2 siblings, 0 replies; 33+ messages in thread From: Gautier @ 1999-08-17 0:00 UTC (permalink / raw) To: Samuel Tardieu > Where did you get the impression that the optimizer would miss this? Good question! I've modified the example with floating-point values and accessed records (nearer to the "real" example) : impossible to fool that diabolical GNAT optimizer. I'll try to refind my test sources. Another nice thing that GNAT does is to re-use the address computation for 2 arrays in 2 different instructions (not too near)! -- Gautier ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-17 0:00 ` Samuel Tardieu 1999-08-17 0:00 ` Gautier @ 1999-08-17 0:00 ` Andi Kleen 1999-08-18 0:00 ` Robert Dewar 1999-08-18 0:00 ` Gautier 2 siblings, 1 reply; 33+ messages in thread From: Andi Kleen @ 1999-08-17 0:00 UTC (permalink / raw) Samuel Tardieu <sam@ada.eu.org> writes: > >>>>> "Gautier" == Gautier <Gautier.deMontmollin@Maths.UniNe.CH> writes: > > Gautier> a(b(c,d+e(f,g)).h(i,j)) := a(b(c,d+e(f,g)).h(i,j)) + 1; > > Gautier> which can be horribily long and unlikely to be catched by the > Gautier> optimizer -> 2x too slow (at least: the extra code makes a > Gautier> penalty for processor cache). > > Where did you get the impression that the optimizer would miss this? [..] discussion about +=,++ and friends for better code snipped. I would like to have += in Ada (perhaps not ++,--) simply because it is more expressive. My brain wraps easier to "increase X by Y" than to "set X to the sum of X and Y"[1] Ada is about making it easy for the reader, isn't it? +=, -= make it clear that there is a side effect that takes the old value into account, with the spelled out way "x := x + 1" I have to determine that first. With simple "x" it is easy, but e.g. with Gautier's example above it requires real mental work that distracts me from my primary job. Not that this is impossible, it is just that the first way is IMHO better readable because it makes the intent of the author more clear. -Andi [1] To attribute correctly this is an old argument from, I believe Dennis Ritchie, in a prehistoric article about C. I think he's right. -- This is like TV. I don't like TV. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-17 0:00 ` Andi Kleen @ 1999-08-18 0:00 ` Robert Dewar 1999-08-17 0:00 ` Brian Rogoff 1999-08-18 0:00 ` Andi Kleen 0 siblings, 2 replies; 33+ messages in thread From: Robert Dewar @ 1999-08-18 0:00 UTC (permalink / raw) In article <m3u2pyutzu.fsf@fred.muc.de>, Andi Kleen <ak-uu@muc.de> wrote: > [1] To attribute correctly this is an old argument from, I believe > Dennis Ritchie, in a prehistoric article about C. I think he's right. No, this is older than C, these notations were around in Algol variants (as +:=) before C existed. Note that Algol-68 has these operators. But there are many other factors in the Ada decision. Please go look up old threads, I don't feel like going over this stuff again myself :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Robert Dewar @ 1999-08-17 0:00 ` Brian Rogoff 1999-08-18 0:00 ` Robert Dewar ` (2 more replies) 1999-08-18 0:00 ` Andi Kleen 1 sibling, 3 replies; 33+ messages in thread From: Brian Rogoff @ 1999-08-17 0:00 UTC (permalink / raw) On Wed, 18 Aug 1999, Robert Dewar wrote: > In article <m3u2pyutzu.fsf@fred.muc.de>, > Andi Kleen <ak-uu@muc.de> wrote: > > [1] To attribute correctly this is an old argument from, I > believe > > Dennis Ritchie, in a prehistoric article about C. I think he's > right. > > > No, this is older than C, these notations were around in > Algol variants (as +:=) before C existed. Note that Algol-68 > has these operators. > > But there are many other factors in the Ada decision. Please > go look up old threads, I don't feel like going over this stuff > again myself :-) Yes, but Algol-68 didn't have a pseudo-variable for representing the left hand side, and I haven't seen this approach discussed here. If it was, please give a pointer of some kind to the thread. Also note that a request for opinions doesn't constitute a suggestion for a language change. I prefer [] for arrays too, but there's no way I'd suggest that change! I was curious about whether other Ada users would find some notation like this *more readable*. I doubt that adding syntactic gadgetry like this at this stage in Ada's life is worth the effort. Ada's progeny are a different story. -- Brian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-17 0:00 ` Brian Rogoff @ 1999-08-18 0:00 ` Robert Dewar 1999-08-18 0:00 ` Brian Rogoff 1999-08-18 0:00 ` Ted Dennison 1999-08-18 0:00 ` Gautier 2 siblings, 1 reply; 33+ messages in thread From: Robert Dewar @ 1999-08-18 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9908172116110.25744-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > Yes, but Algol-68 didn't have a pseudo-variable for representing the left > hand side, and I haven't seen this approach discussed here. If it was, > please give a pointer of some kind to the thread. The pseudo-variable proposal seems entirely horrible to me, and indeed was not discussed at all. I can see all kinds of abuse and very little gain from this syntactic vinegar :-) The idea of the evaluation of the right hand side being tied in semantically to the evaluation of the left hand side like this seems quite nasty to me, a real confusion in the fundamental semantics of assignment. Right now the semantics attributes of assignment are purely inherited, and you really want to keep things this way. Maybe I missed something, but I did not see any significant support for this particular notion, the discussion was almost all about the much cleaner (though still fraught with problems)+= type notation. I consider a renaming to be much cleaner for a reader than the use of your pseudo-variable (the latter is just syntactic sugar/vinegar for the former presumably???) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Robert Dewar @ 1999-08-18 0:00 ` Brian Rogoff 1999-08-19 0:00 ` Robert Dewar 0 siblings, 1 reply; 33+ messages in thread From: Brian Rogoff @ 1999-08-18 0:00 UTC (permalink / raw) On Wed, 18 Aug 1999, Robert Dewar wrote: > The pseudo-variable proposal seems entirely horrible to me, and > indeed was not discussed at all. I can see all kinds of abuse > and very little gain from this syntactic vinegar :-) ROTFL! That little expression (syntactic vinegar) was the high point of a bland day. Is that an original Dewarism? > The idea of the evaluation of the right hand side being tied > in semantically to the evaluation of the left hand side like > this seems quite nasty to me, a real confusion in the > fundamental semantics of assignment. Right now the semantics > attributes of assignment are purely inherited, and you really > want to keep things this way. > > Maybe I missed something, but I did not see any significant > support for this particular notion, the discussion was almost > all about the much cleaner (though still fraught with > problems)+= type notation. > > I consider a renaming to be much cleaner for a reader than > the use of your pseudo-variable (the latter is just syntactic > sugar/vinegar for the former presumably???) You presume correctly. I haven't seen the original language which did this, Mode, since I think most of the docs are in Finnish. I saw this idea described in Markku Sakkinen's C++ critique, and I thought it was a neat idea. Some people like things like this, some don't. Obviously, I'm not so dense that I find I = I + 1 and the like to be a problem, but for complex array operations like the example Gautier presented and other such things, I find this notation much easier reading than renaming. If there are nasty semantics issues, and great potential for misuse, that's another issue. I wonder if C and C++ programmers find this stuff more readable? I'm certainly in that category myself, meaning that I write C and C++ code (and enjoy it!) even though in those cases that I use C I would generally prefer Ada given the choice. A more general point about "readability" is that its a pretty vague notion, and I sometimes find Ada's verbosity a detriment to readability. -- Brian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Brian Rogoff @ 1999-08-19 0:00 ` Robert Dewar 1999-08-21 0:00 ` Brian Rogoff 1999-08-23 0:00 ` Robert A Duff 0 siblings, 2 replies; 33+ messages in thread From: Robert Dewar @ 1999-08-19 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9908182033010.14398-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > On Wed, 18 Aug 1999, Robert Dewar wrote: > > The pseudo-variable proposal seems entirely horrible to me, and > > indeed was not discussed at all. I can see all kinds of abuse > > and very little gain from this syntactic vinegar :-) > > ROTFL! > > That little expression (syntactic vinegar) was the high point of a bland > day. Is that an original Dewarism? no, no, that's as old as programming languages as far as I know, certainly it dates back to the 60's .. :-) but i appreciate the ROTFL, anything to brighten up an otherwise dull day! Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-19 0:00 ` Robert Dewar @ 1999-08-21 0:00 ` Brian Rogoff 1999-08-23 0:00 ` Robert A Duff 1 sibling, 0 replies; 33+ messages in thread From: Brian Rogoff @ 1999-08-21 0:00 UTC (permalink / raw) On Thu, 19 Aug 1999, Robert Dewar wrote: > In article > <Pine.BSF.4.10.9908182033010.14398-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > On Wed, 18 Aug 1999, Robert Dewar wrote: > > > The pseudo-variable proposal seems entirely horrible to me, > and > > > indeed was not discussed at all. I can see all kinds of > abuse > > > and very little gain from this syntactic vinegar :-) > > > > ROTFL! > > > > That little expression (syntactic vinegar) was the high point > of a bland > > day. Is that an original Dewarism? > > no, no, that's as old as programming languages as far as I know, > certainly it dates back to the 60's .. :-) but i appreciate the > ROTFL, anything to brighten up an otherwise dull day! Well, I guess I'm showing my age! I remember certain expressions like "the ratchet effect" (you can never remove language features) and LALR parser generators as "all that stuff done in the 70's to make parsers slow" as coming from you, don't tell me they're ancient too? To bring it back on topic, the "op:=" like +:= is not just in Algol-68, which is stagnant, but also used in Icon and its successor. So there are living languages using this "vampire" notation :-) -- Brian ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-19 0:00 ` Robert Dewar 1999-08-21 0:00 ` Brian Rogoff @ 1999-08-23 0:00 ` Robert A Duff 1 sibling, 0 replies; 33+ messages in thread From: Robert A Duff @ 1999-08-23 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article > <Pine.BSF.4.10.9908182033010.14398-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > On Wed, 18 Aug 1999, Robert Dewar wrote: > > > The pseudo-variable proposal seems entirely horrible to me, > and > > > indeed was not discussed at all. I can see all kinds of > abuse > > > and very little gain from this syntactic vinegar :-) > > > > ROTFL! > > > > That little expression (syntactic vinegar) was the high point > of a bland > > day. Is that an original Dewarism? > > no, no, that's as old as programming languages as far as I know, > certainly it dates back to the 60's .. :-) but i appreciate the > ROTFL, anything to brighten up an otherwise dull day! During the design of Ada 95, somebody called the "select ... then abort" syntax "syntactic poison", which made this dangerous and controversial feature more acceptable to some reviewers -- it had previously had a more innocuous-looking syntax (which I can't remember). - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-17 0:00 ` Brian Rogoff 1999-08-18 0:00 ` Robert Dewar @ 1999-08-18 0:00 ` Ted Dennison 1999-08-18 0:00 ` Robert I. Eachus 1999-08-18 0:00 ` Jeff Carter 1999-08-18 0:00 ` Gautier 2 siblings, 2 replies; 33+ messages in thread From: Ted Dennison @ 1999-08-18 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9908172116110.25744-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > suggest that change! I was curious about whether other Ada users would > find some notation like this *more readable*. I doubt that adding If you are soliciting opinions, I think its beyond ugly. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Ted Dennison @ 1999-08-18 0:00 ` Robert I. Eachus 1999-08-18 0:00 ` Jeff Carter 1 sibling, 0 replies; 33+ messages in thread From: Robert I. Eachus @ 1999-08-18 0:00 UTC (permalink / raw) Ted Dennison wrote: > If you are soliciting opinions, I think its beyond ugly. Agreed. There is a very subtle and painful problem with the Ada notation. A := A + 1; in Ada 83 could raise an exception. If it did A would have to remain unchanged in the exception handler, and if shared, if read by any other task. (A was never modified, so no intervening synchronization point was required.) This meant that the code could not use an increment instruction on many processor architectures. In Ada 95, 11.6(6) among other things allows increments to be used here. That was a very strong argument in Ada 83 for implementations and users to find a better way to get the += semantics. A lot of proposals were discussed, including both language "fixes" and implementation defined extensions. None of them ever caught on, because as people learned the language better they discovered that: In many cases where a fast increment was needed, the variable was a loop variable and the problem didn't arise. (Well once the compiler writers figured that the "right" Ada sequence to generate for the loop check is to check before the increment. Since the variable is never visible outside the loop, you don't need C or Fortran semantics.) In other cases, such as circular buffers, the user is the one who should do the check: "if Index = Buffer'Last then Index := Buffer'First else Index := Index + 1;" (Of course in Ada 95, you can do this with a modular type.) In many other cases where you wanted a fast increment the better way in Ada was to write at a higher level for example assigning slices instead of doing an element by element copy. So the need for any feature like this has almost completely gone away. (In C, I find I use one of these special forms at least every ten lines, mostly in loop declarations. In Ada, I am unlikely to "miss" one of them in several hundred lines, even if I am doing a direct translation from C. (Yes, I know, why translate from C? It is much easier on some code than putting in all the missing checks.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Ted Dennison 1999-08-18 0:00 ` Robert I. Eachus @ 1999-08-18 0:00 ` Jeff Carter 1999-08-18 0:00 ` Keith Thompson 1 sibling, 1 reply; 33+ messages in thread From: Jeff Carter @ 1999-08-18 0:00 UTC (permalink / raw) To: comp.lang.ada@list.deja.com I recall something like this A_Nice_Long_Name := @ ** 2 + @ + 1.0 / @ + C; in a revision request. Obviously it was not incorporated into the language. One problem with this kind of syntax can be seen from the following example: type Rec is record I : Integer; end record; type Rec_Ptr is access all Rec; Count : Natural := 0; function Side_Effects return Rec_Ptr is Result : Rec_Pointer := new Rec; begin -- Side_Effects Count := Count + 1; Result.I := Count; return Result; end Side_Effects; ... Side_Effects.I := @ + @ / 2 + 1; What is the value of Count after executing this statement? Jeff "Now go away or I shall taunt you a second time." Monty Python & the Holy Grail Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Jeff Carter @ 1999-08-18 0:00 ` Keith Thompson 1999-08-19 0:00 ` Michael F. Yoder 1999-08-19 0:00 ` Tarjei T. Jensen 0 siblings, 2 replies; 33+ messages in thread From: Keith Thompson @ 1999-08-18 0:00 UTC (permalink / raw) Jeff Carter <jcarter@CapAccess.org> writes: [...] > One problem with this kind of syntax can be seen from the following example: > > type Rec is record > I : Integer; > end record; > > type Rec_Ptr is access all Rec; > > Count : Natural := 0; > > function Side_Effects return Rec_Ptr is > Result : Rec_Pointer := new Rec; > begin -- Side_Effects > Count := Count + 1; > Result.I := Count; > > return Result; > end Side_Effects; > > ... > > Side_Effects.I := @ + @ / 2 + 1; > > What is the value of Count after executing this statement? No problem; the value of Count is 1. An occurrence of @ doesn't cause the left hand side to be re-evaluated, it merely refers to the object whose name has already been evaluated. (At least that's how I'd define it.) More precisely, the statement Side_Effects.I := @ + @ / 2 + 1; would be equivalent to declare _LHS_ : _some_type_ renames Side_Effects.I; begin _LHS_ := _LHS_ + _LHS_ / 2 + 1; end; with the proper substitutions for _LHS_ and _some_type_. I don't think defining the semantics is terribly difficult. The real issue is that most people here seem to think it's unbearably ugly. I don't agree -- it's not exactly pretty, but I think the convenience would be worth it. Perhaps I've been contaminated by several years of C and Perl. I suspect a syntax other than @ would make it more bearable to some -- perhaps a new reserved word. Others have suggested things like a generic Inc procedure or a renames declaration to achieve similar effects. These work, but I haven't seen them used much in practice. The reason: they both require an extra declaration, and possibly a new scope, for something that's supposed to be a shorthand within a single assignment statement. Remember that C's funky operators like ++, +=, and so on are dangerous largely because they have side effects *and* return results. (So does ordinary assignment.) The proposed @ shorthand doesn't have this problem. For example, C lets you write thinks like "i = i++", which produces undefined behavior; the @ shorthand doesn't allow such things. I'm well aware that there's little or no chance of this being added to some future version of Ada (which makes this whole thread somewhat off-topic, I suppose). I'm just saying that I like the idea, and I wouldn't mind seeing it in some future language. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Keith Thompson @ 1999-08-19 0:00 ` Michael F. Yoder 1999-08-21 0:00 ` Keith Thompson 1999-08-19 0:00 ` Tarjei T. Jensen 1 sibling, 1 reply; 33+ messages in thread From: Michael F. Yoder @ 1999-08-19 0:00 UTC (permalink / raw) Keith Thompson wrote: > I'm well aware that there's little or no chance of this being added to > some future version of Ada (which makes this whole thread somewhat > off-topic, I suppose). I'm just saying that I like the idea, and I > wouldn't mind seeing it in some future language. Consider the case Highly_Overloaded_Function.all := F(@, G(@, @)); Is it your intent that overload resolution use the fact that @ denote the *same* meaning as the left side in each case? Can you adjust overload resolution in a reasonably simple way to accommodate this? -- Michael F. Yoder Unscientific man is beset by a deplorable desire to have been right. The scientist is distinguished by a desire to *be* right. -- W.V. Quine ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-19 0:00 ` Michael F. Yoder @ 1999-08-21 0:00 ` Keith Thompson 0 siblings, 0 replies; 33+ messages in thread From: Keith Thompson @ 1999-08-21 0:00 UTC (permalink / raw) "Michael F. Yoder" <yoder@decada.zko.dec.com> writes: > Consider the case > > Highly_Overloaded_Function.all := F(@, G(@, @)); > > Is it your intent that overload resolution use the fact that @ denote > the *same* meaning as the left side in each case? Um, yes, I suppose so. > Can you adjust > overload resolution in a reasonably simple way to accommodate this? Not without a lot more mental effort than I'm willing to expend. 8-)} -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Keith Thompson 1999-08-19 0:00 ` Michael F. Yoder @ 1999-08-19 0:00 ` Tarjei T. Jensen 1999-08-19 0:00 ` Ted Dennison ` (3 more replies) 1 sibling, 4 replies; 33+ messages in thread From: Tarjei T. Jensen @ 1999-08-19 0:00 UTC (permalink / raw) Keith Thompson wrote: > I'm well aware that there's little or no chance of this being added to > some future version of Ada (which makes this whole thread somewhat > off-topic, I suppose). I'm just saying that I like the idea, and I > wouldn't mind seeing it in some future language. So would I. I don't care much for [+-*/]= as I too think it is ugly. However using @ or a functional equivalent seems to be worthwhile. It may make some code much more readable than it would otherwise be. I don't know if safety critical applications would want to use it, but it would be simple to expand the @s before using the source. So count me in on those who prefer a := @ + 1; over a += 1; Greetings, ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-19 0:00 ` Tarjei T. Jensen @ 1999-08-19 0:00 ` Ted Dennison 1999-08-19 0:00 ` Lance Kibblewhite ` (2 subsequent siblings) 3 siblings, 0 replies; 33+ messages in thread From: Ted Dennison @ 1999-08-19 0:00 UTC (permalink / raw) In article <37BBA5E1.13FBF70E@kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > Keith Thompson wrote: > > I'm well aware that there's little or no chance of this being added to > > some future version of Ada (which makes this whole thread somewhat > > off-topic, I suppose). I'm just saying that I like the idea, and I > > wouldn't mind seeing it in some future language. > > So would I. I don't care much for [+-*/]= as I too think it is ugly. > However using @ or a functional equivalent seems to be worthwhile. It > may make some code much more readable than it would otherwise be. I I personally don't agree that swapping perfectly good identifiers for line noise characters will make things more readable. But if you do feel that way, it would be trivial to implement it in a precompiler. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-19 0:00 ` Tarjei T. Jensen 1999-08-19 0:00 ` Ted Dennison @ 1999-08-19 0:00 ` Lance Kibblewhite 1999-08-19 0:00 ` Robert Dewar 1999-08-19 0:00 ` tmoran 3 siblings, 0 replies; 33+ messages in thread From: Lance Kibblewhite @ 1999-08-19 0:00 UTC (permalink / raw) Tarjei T. Jensen wrote: >Keith Thompson wrote: >> I'm well aware that there's little or no chance of this being added to >> some future version of Ada (which makes this whole thread somewhat >> off-topic, I suppose). I'm just saying that I like the idea, and I >> wouldn't mind seeing it in some future language. > >So would I. I don't care much for [+-*/]= as I too think it is ugly. >However using @ or a functional equivalent seems to be worthwhile. It >may make some code much more readable than it would otherwise be. I >don't know if safety critical applications would want to use it, but it >would be simple to expand the @s before using the source. > >So count me in on those who prefer a := @ + 1; over a += 1; Since we are counting :-), count me out. There are two issues. 1) Indication of modification of the LHS, as opposed to replacement. For this, I do prefer the '+=' approach. 2) A shorthand for reducing the possibility of error in duplicating complex expressions. For this, consider this situation: declare Exp1 : <whatever> renames <first complicated expression> Exp2 : <whatever> renames <second complicated expression> begin Exp1 := Exp2 - Exp1 / Exp2 + 1; end; 'Renames' is much more versatile. The use of a 'special' notation to reflect the LHS only seems too specialized. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-19 0:00 ` Tarjei T. Jensen 1999-08-19 0:00 ` Ted Dennison 1999-08-19 0:00 ` Lance Kibblewhite @ 1999-08-19 0:00 ` Robert Dewar 1999-08-20 0:00 ` P.S. Norby 1999-08-19 0:00 ` tmoran 3 siblings, 1 reply; 33+ messages in thread From: Robert Dewar @ 1999-08-19 0:00 UTC (permalink / raw) In article <37BBA5E1.13FBF70E@kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: . I > don't know if safety critical applications would want to use > it, That's a *really* odd comment. If this notation is any use at all it is useful to make sources more readable and understandable (either informally or formally). The suggestion that it is somehow unsafe is entirely peculiar. > but it > would be simple to expand the @s before using the source. Surely not! It never occurred to me that people intended this as having macro substitution semantics. UGH! shades of the unexpected effects of using ++ within C defines. > So count me in on those who prefer a := @ + 1; over a += 1; The notation a += 1; is entirely foreign to Ada style syntax, it is a C-ism which has no more place in Ada than the (rather horrible) C assignment syntax: a = 1; The proper syntactic form for this in Ada would be (borrowing from the Algol tradition which is the fundamental inspiration for Ada syntax); a +:= 1; The problems with the above notation are not syntactic, they are semantic, and have been discussed at length previously. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-19 0:00 ` Robert Dewar @ 1999-08-20 0:00 ` P.S. Norby 1999-08-21 0:00 ` Robert Dewar 0 siblings, 1 reply; 33+ messages in thread From: P.S. Norby @ 1999-08-20 0:00 UTC (permalink / raw) Robert Dewar wrote: > > a +:= 1; > +:= A vampire with a cross on its head? P. S. Norby "Software engineers are, in many ways, similar to normal people" -- Scott Adams "No excuses. No embarrassment. No apologies... Ada -- the most trusted and powerful programming language on earth, or in space." -- S. Tucker Taft \\\ \\\ \\\ \\\ \\\ \\\ \\\ \\\ \\\ ( :) ( :) ( :) ( :) ( :) ( :) ( :) ( :) ( :) /// /// /// /// /// /// /// /// /// (Speaking only for myself) ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-20 0:00 ` P.S. Norby @ 1999-08-21 0:00 ` Robert Dewar 0 siblings, 0 replies; 33+ messages in thread From: Robert Dewar @ 1999-08-21 0:00 UTC (permalink / raw) In article <37BD5069.6D6E@cacd.rockwell.com>, "P.S. Norby" <psnorby@cacd.rockwell.com> wrote: > > +:= > > A vampire with a cross on its head? An interesting interpretation :-) But seriously, a *very* familiar notation to those of us who have been exposed to more than one or two programming languages :-) and much more consistent with an Algol-style syntax. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-19 0:00 ` Tarjei T. Jensen ` (2 preceding siblings ...) 1999-08-19 0:00 ` Robert Dewar @ 1999-08-19 0:00 ` tmoran 3 siblings, 0 replies; 33+ messages in thread From: tmoran @ 1999-08-19 0:00 UTC (permalink / raw) >However using @ or a functional equivalent seems to be worthwhile. Like a pronoun? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-17 0:00 ` Brian Rogoff 1999-08-18 0:00 ` Robert Dewar 1999-08-18 0:00 ` Ted Dennison @ 1999-08-18 0:00 ` Gautier 2 siblings, 0 replies; 33+ messages in thread From: Gautier @ 1999-08-18 0:00 UTC (permalink / raw) > Also note that a request for opinions doesn't constitute a suggestion for > a language change. I prefer [] for arrays too, but there's no way I'd > suggest that change! I was curious about whether other Ada users would > find some notation like this *more readable*. I doubt that adding > syntactic gadgetry like this at this stage in Ada's life is worth the > effort. Ada's progeny are a different story. My opinion: the "+=" and such notation are not readable at all. The main advantage of Ada is that you can spell the instructions and it means something. It's important for many areas of programming where you have to re-read and understand your (or worse: other's) code. Adding these notations would be a leap back to these 1960s cryptic, write-only, macro-assemblers made for experimenting new operating systems and now (too often) used in improper areas like scientific programming or large-scale projects... I prefer to keep the +=*%^$ notations for such applets: ================================================================== #include <io.h> float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L|| (h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<L?--_ %6:6:7)+"World! \n",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;} ================================================================== In fact the generic Inc / Add do the job, now, without adding anything! -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-18 0:00 ` Robert Dewar 1999-08-17 0:00 ` Brian Rogoff @ 1999-08-18 0:00 ` Andi Kleen 1 sibling, 0 replies; 33+ messages in thread From: Andi Kleen @ 1999-08-18 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <m3u2pyutzu.fsf@fred.muc.de>, > Andi Kleen <ak-uu@muc.de> wrote: > > [1] To attribute correctly this is an old argument from, I > believe > > Dennis Ritchie, in a prehistoric article about C. I think he's > right. > > > No, this is older than C, these notations were around in > Algol variants (as +:=) before C existed. Note that Algol-68 > has these operators. So was the argument "x+=1 is more human brain and code review friendly than x:=x+1" already used during Algol development? I was just attributing where I read this particular point first. I guess the reason why it wasn't included in Pascal is that Wirth was too hooked to pure mathematical thinking where they of course equivalent (ignoring that x:=x+1 is per see mathematical nonsense, either x is x or it is x+1, but not both @) > But there are many other factors in the Ada decision. Please > go look up old threads, I don't feel like going over this stuff > again myself :-) I don't intend to, I understand that it is unrealistic and will probably never happen to Ada. I just couldn't resist to bring another view to the boring "+= helps the optimizer" discussions. -Andi -- This is like TV. I don't like TV. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-17 0:00 ` Samuel Tardieu 1999-08-17 0:00 ` Gautier 1999-08-17 0:00 ` Andi Kleen @ 1999-08-18 0:00 ` Gautier 2 siblings, 0 replies; 33+ messages in thread From: Gautier @ 1999-08-18 0:00 UTC (permalink / raw) > Gautier> a(b(c,d+e(f,g)).h(i,j)) := a(b(c,d+e(f,g)).h(i,j)) + 1; > Gautier> which can be horribily long and unlikely to be catched by the > Gautier> optimizer -> 2x too slow (at least: the extra code makes a > Gautier> penalty for processor cache). > Where did you get the impression that the optimizer would miss this? > [ the proof that GNAT with -O3 (in fact even -O2) does see it and puts an "intrinsic" Inc( a(b(c,d+e(f,g)).h(i,j)) ); ] NB: tested with the generic, inlined Inc procedure the assembler output is exaclty the same :-) Subsidiary question: are other optimizers so good (ObjectAda, Janus,...) ? [Did I ask the same question 1 year ago ? I'll check in DN...] -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-16 0:00 ` Gautier 1999-08-17 0:00 ` Samuel Tardieu @ 1999-08-17 0:00 ` John Duncan 1999-08-17 0:00 ` Gautier 1 sibling, 1 reply; 33+ messages in thread From: John Duncan @ 1999-08-17 0:00 UTC (permalink / raw) > a(b(c,d+e(f,g)).h(i,j)) := a(b(c,d+e(f,g)).h(i,j)) + 1; 1. Who is writing this code? 2. Is this code being looped through so many times that the optimization is going to cause a significant decrease on execution times? 3. For whom is the ++ solution optimal? -John ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-17 0:00 ` John Duncan @ 1999-08-17 0:00 ` Gautier 0 siblings, 0 replies; 33+ messages in thread From: Gautier @ 1999-08-17 0:00 UTC (permalink / raw) John Duncan wrote: > > a(b(c,d+e(f,g)).h(i,j)) := a(b(c,d+e(f,g)).h(i,j)) + 1; > 1. Who is writing this code? Not me, but it exists and I assure you that "a(b(c,d+e(f,g)).h(i,j))" is not a badly written expression in that context... > 2. Is this code being looped through so many times that the optimization is > going to cause a significant decrease on execution times? I've seen such things in the heart of quintuple loops in critical parts of a program, so I guess that an optimization is welcome... > 3. For whom is the ++ solution optimal? What a question! -- Gautier -------- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: C like op= proposal 1999-08-15 0:00 C like op= proposal Brian Rogoff 1999-08-15 0:00 ` Ray Blaak @ 1999-08-16 0:00 ` Robert Dewar 1 sibling, 0 replies; 33+ messages in thread From: Robert Dewar @ 1999-08-16 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9908151023060.10801-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > Was anything like this ever discussed for Ada? Assuming some acceptable > notation was chosen for the pseudo-variable ("_" works, but stands out > less to my eye than "@"), would people find this more or less readable > than the current verbose approach? Yes, of course, and it has been the subject of several CLA threads, I know of no new arguments that would support any change in the original design here. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~1999-08-23 0:00 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-08-15 0:00 C like op= proposal Brian Rogoff 1999-08-15 0:00 ` Ray Blaak 1999-08-15 0:00 ` Brian Rogoff 1999-08-16 0:00 ` Gautier 1999-08-17 0:00 ` Samuel Tardieu 1999-08-17 0:00 ` Gautier 1999-08-17 0:00 ` Andi Kleen 1999-08-18 0:00 ` Robert Dewar 1999-08-17 0:00 ` Brian Rogoff 1999-08-18 0:00 ` Robert Dewar 1999-08-18 0:00 ` Brian Rogoff 1999-08-19 0:00 ` Robert Dewar 1999-08-21 0:00 ` Brian Rogoff 1999-08-23 0:00 ` Robert A Duff 1999-08-18 0:00 ` Ted Dennison 1999-08-18 0:00 ` Robert I. Eachus 1999-08-18 0:00 ` Jeff Carter 1999-08-18 0:00 ` Keith Thompson 1999-08-19 0:00 ` Michael F. Yoder 1999-08-21 0:00 ` Keith Thompson 1999-08-19 0:00 ` Tarjei T. Jensen 1999-08-19 0:00 ` Ted Dennison 1999-08-19 0:00 ` Lance Kibblewhite 1999-08-19 0:00 ` Robert Dewar 1999-08-20 0:00 ` P.S. Norby 1999-08-21 0:00 ` Robert Dewar 1999-08-19 0:00 ` tmoran 1999-08-18 0:00 ` Gautier 1999-08-18 0:00 ` Andi Kleen 1999-08-18 0:00 ` Gautier 1999-08-17 0:00 ` John Duncan 1999-08-17 0:00 ` Gautier 1999-08-16 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox