++ and += operators

[Mike Cowlishaw-3]

I miss those, too .. equally, they seem to be particularly
'surprising' notations for someone who hasn't seen them before.
Any other suggestions?

One that has been proposed is simply that any clause of the form:

  var op expression

is treated as  var=var op expression

For example:

   N+1

means 'add 1 to M'

--
Mike Cowlishaw
IBM Fellow, IBM UK Laboratories
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Nicholas J Gimbrone (Whatever Is Right-Do It)]

>  var op expression
>is treated as  var=var op expression
I find this much more confusing than the notation:
   var op= expression
I think the explicit "=" in "op=" is helpful to noting that this is
an assignment, not a typo for something like "missing var op expression".
Peace. -njg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Patrick McPhee-3]

Mike Cowlishaw wrote

> For example:
>
>    N+1
>
> means 'add 1 to M'
>
>
This _would_ be surprising. Would M+1 add 1 to L or to N? If N, would
L+1 add 1 to K or to O?
Seriously, I think N += 1 is less `surprising' than the proposed
notation (but I am a C programmer with more than a decade's experience,
so my opinion probably isn't worth so much). In my view, the difficulty
with ++ notation isn't so much that
 n++
a surprising way to increment n (m?) as that
 function(++n,n++,m++,++l,k++)
can have unpredictable results unless you fully specify the order of
argument evaluation. In fact, leaving a fairly pathological case aside,
 function(n++)
can have confusing results to a novice.

If you were thinking of adding operators, I vote for the inclusion of
+=, -=, et al, in the interest of adding an elegant short-hand, and the
exclusion of ++ and --, because they're a bit odd and -- is used already
anyway.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Massimiliano Marsiglietti]

Ciao,

> I miss those, too .. equally, they seem to be particularly
> 'surprising' notations for someone who hasn't seen them before. Any
> other suggestions?

What about:

add 1 to  M
subtract 3 to  M

Ok, don't shoot me, my fiancee is COBOL-addicted and is reading the
mail with me right now. :-)

Max & Cri
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Chip Davis-2]

I'm afraid I've been following this thread with a growing unease.  As one
who teaches Rexx to non-programmers, I am eternally grateful to Mike for
keeping the language simple in the face of constant pressure to C-ize it.
Running '++' and '+=' past my internal RAF-sensor sets off alarms.

That said, I recognize that NetRexx is not Classic Rexx, and there are
already many aspects of NetRexx that make programming less-easier than
before (most of which I lay at the feet of Java).  Recalibrating my
RAF-sensor upwards to take that into account, and ...

Yep, it still goes off.

We _are_ using much longer names these days, so the problem is legitimate.
I think Mike's suggestion:

>   var op expression
>  
> is treated as  var=var op expression

is more Rexx-ish.  It is elegant, avoids the duplication of long names,
does not add more cryptic operators, and is easily explained to neophytes.

The only drawback I see to this construction results from the overloading
of the '=' operator: does 'x=3' mean 'assign the value 3 to the variable
x', or 'compare the value referenced by x to the value 3, and place the
boolean result in x' ?  Since the latter is equivalent to x = x = 3 (which
also sets off my RAF-o-meter) and can be better expressed as x = (x=3), a
not too burdensome workaround would be:

   x = 3   -- assign 3 to x
  (x = 3)  -- compare x to 3 and assign boolean to x

This would allow us to say:

  (anExtremelyLongNameForAProperty + (anEquallyLongIndexValue * 8))

and make almost everyone happy.  Unless I'm missing something ...

-Chip Davis-      Aresti Systems   Member of: Rexx Language Association
[hidden email]   P.O.Box 13306               ANSI Rexx Standard Committee
919.303.3306      RTP NC 27709-3306           TeamOS/2 & Thoroughly Warped!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[K.-P. Kirchdoerfer]

On Thu, 4 Dec 1997 15:41:10 -0500, Patrick McPhee wrote:

>Mike Cowlishaw wrote
>
>> For example:
>>
>>    N+1
>>
>> means 'add 1 to M'
>>
>>
>This _would_ be surprising. Would M+1 add 1 to L or to N? If N, would
>L+1 add 1 to K or to O?
>Seriously, I think N += 1 is less `surprising' than the proposed
>notation (but I am a C programmer with more than a decade's experience,
>so my opinion probably isn't worth so much). In my view, the difficulty

[snip]

I've learned REXX as a non-programmer very easily 'cause the
programming language has been not too far away from a natural
language - and therefor to think in Rexx has been as easy as thinking
in any other non-native language. (Well, it's just english and Rexx
for today...)

Although netrexx is somewhat different from Rexx, the
expression N+1 can IMHO more easily complemented to N=N+1 in my mind.
If I see 3+1 I also see 4.
But what if I see 3+=1? Maybe a honorable, weird C-programmer, but of
course not 4.


regards kp
--
K.P.Kirchdoerfer                      Voice:   [phone]
24116 Kiel                            E-Mail: [hidden email]

Mission Of Dead Souls


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Scott Pollard]

Well, I'm personally sorry to see the clarity of Rexx now being hijacked by
the obscurity of a really rather elderly language ("C") and some constructs
(like += and, of course =+) developed to enable one or two bytes to be
shaved off source code files.

And before anyone writes "you don't have to use them" -- remember clarity
is in what you READ, not what you write.  If these constructs are there,
others use them -- then it's their code, and I may still have to try to
understand it.

My vote is -- keep (net)Rexx pure, keep C out!!

But maybe I know nothing -- I've only been programming for 30 years so
perhaps I'm too set in my ways ?! "<grin>", is, I understand, appropriate
here!! <wink>

Scott P.

----------
From: Mike Cowlishaw <[hidden email]>
To: [hidden email]
Subject: ++ and += operators
Date: Thursday, December 04, 1997 5:35 PM

I miss those, too .. equally, they seem to be particularly
'surprising' notations for someone who hasn't seen them before.
Any other suggestions?

One that has been proposed is simply that any clause of the form:

  var op expression

is treated as  var=var op expression

For example:

   N+1

means 'add 1 to M'

--
Mike Cowlishaw
IBM Fellow, IBM UK Laboratories
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note
to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Martin Lafaix]

M
My personal list of « things that would be gorgeous to have » is
quite long, but I think most of them fall in the « used only once
or twice » category.  So I decided to check how frequently I would
use the proposed enhancements.

Out of the 5039 lines of NetRexx code I wrote (not including
comments or empty lines), 1255 are assignments or declaration
(that is, something of the form « xxxx = .... »).

Out of these 1255 lines (which is an overestimation of the number
of assignments, as it contains type definition for some local
variables and properties), 127 are in the form of « xx = f(xx) »
(that is, self-referent assignments).

Out of these 127 lines, 66 are of the form « xx = xx ... » (that
is, others are for example « x = Math.max(x,y) » or « x = 'n' x »
or « x = x.strip »).

[And, out of these 66 lines, 11 are not easily expressed with the
 += style, as they use the space or direct concatenation operator,
 that is, something like « foo = foo bar » or « foo = foo'.' ».]

So, in symbols saved, now:

- method 1 (« x+1 »):    389 symbols would have been saved.

- method 2 (« x += 1 »): 362 symbols would have been saved.

Impressive :-)

So, putting things back into perspective:

Total sourcecode size : 5944 lines, 215818 symbols (counting
comments and empty lines).

Gain: less than 0.2% in typing.

Does it worth it?  I personally don't think so.  (But I would like
to point that I'm probably sparse on such assignments, having a
quite long functional programming background, where 'mutable'
variables are either nonexistent or considered a Bad Thing(tm).)

[It such an « enhancement » has to be added, I would vote for
 method 2, since it at least does not induce incompatibility
 with existing code.]


Martin
--
[hidden email]
Team OS/2
http://wwwi3s.unice.fr/~lafaix

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[Patrick McPhee-3]

Chip Davis wrote:

[...]
> I am eternally grateful to Mike for
> keeping the language simple in the face of constant pressure to C-ize
> it.
> Running '++' and '+=' past my internal RAF-sensor sets off alarms.
>
I agree with the first sentence I've quoted. I agree that the ++
operator is a bad and confusing thing, and is not especially useful (its
primary use in C is replaced by Rexx's looping constructs). I'll make
another argument about += et al in a moment. I lay awake half the night
trying to figure out what RAF stands for. I have drawn a blank. What
does it stand for?

[...]

> I think Mike's suggestion:
>
> >   var op expression
> >  
> > is treated as  var=var op expression
>
> is more Rexx-ish.
>
Leaving aside Chip's concern about = as a boolean operator for the
moment, I find this notation difficult. K.P.Kirchdoerfer, in another
message, pointed out that when we see
  3 + 1
we think
  4
but we don't think this is the same as changing the value of 3 to 4. 3
+= 1 is not something that makes sense, and it is not the same as a +=
b.

A few others have suggested that += is merely a notational convenience
which saves a few keystrokes at the price of clarity, but I don't agree.
Adding a value to, or subtracting a value from, a variable is, in my
opinion, a distinct operation. It is conceptually different from
calculating the sum of two variables and assigning the result to one of
the two variables. Furthermore, it's not a type of addition, it's a type
of assignment (it assigns a new value relative to the current value). I
suggest that x += y is a simpler idea than x = x + y. I have already
discounted my opinion on the grounds that I'mused to += as a notation,
but I think anyone who is used to x = x+y as a notation should also
discount their opinions.

To come back to Chip's idea
 (x=y) is equivalent to x = (x=y)
this confusion does not arise if you think of op= as a unique type of
asignement, as opposed to a macro expansion for `= op'. Conceptually,
relative assignment doesn't make sense for boolean variables, any more
than, say, multiplication does.

So, I think the idea of relative assignment operations is a good one,
but I also think that you must introduce new operators or it becomes
unweildy to explain. Given that there are operators in use in a closely
related language (meaning Java), if these operators are added to
NetRexx, I think they should use the same notation. This is how I would
explain the two notations under discussion:

v += e
adds the result of the expression e to the variable v

v + e
if used as an expression, returns the sum of v and e. In this case v can
be any expression. If used as a statement adds the result of expression
e to the variable v. In this case, v must be a variable.

--
Patrick TJ McPhee
DataMirror Corporation
[hidden email]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>