C like op= proposal

C like op= proposal

[Brian Rogoff]

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

Re: C like op= proposal

[Ray Blaak]

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.

Re: C like op= proposal

[Brian Rogoff]

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

Re: C like op= proposal

[Robert Dewar]

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.

Re: C like op= proposal

[Gautier]

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

Re: C like op= proposal

[John Duncan]

>   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

Re: C like op= proposal

[Gautier]

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/

Re: C like op= proposal

[Gautier]

> 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

Re: C like op= proposal

[Brian Rogoff]

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

Re: C like op= proposal

[Samuel Tardieu]

>>>>> "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;

Re: C like op= proposal

[Andi Kleen]

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.

Re: C like op= proposal

[Robert Dewar]

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.

Re: C like op= proposal

[Gautier]

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

Re: C like op= proposal

[Robert Dewar]

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.

Re: C like op= proposal

[Ted Dennison]

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.

Re: C like op= proposal

[Jeff Carter]

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.

Re: C like op= proposal

[Gautier]

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

Re: C like op= proposal

[Brian Rogoff]

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

Re: C like op= proposal

[Andi Kleen]

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.

Re: C like op= proposal

[Keith Thompson]

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.

Re: C like op= proposal

[Robert I. Eachus]

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

Re: C like op= proposal

[Lance Kibblewhite]

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.

Re: C like op= proposal

[tmoran]

>However using @ or a functional equivalent seems to be worthwhile.
  Like a pronoun?

Re: C like op= proposal

[Robert Dewar]

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.

Re: C like op= proposal

[Michael F. Yoder]

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

Re: C like op= proposal

[Robert Dewar]

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.

Re: C like op= proposal

[Tarjei T. Jensen]

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,

Re: C like op= proposal

[Ted Dennison]

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.

Re: C like op= proposal

[P.S. Norby]

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)

Re: C like op= proposal

[Robert Dewar]

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.

Re: C like op= proposal

[Brian Rogoff]

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

Re: C like op= proposal

[Keith Thompson]

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

Re: C like op= proposal

[Robert A Duff]

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.