A (my) proposal for an IMPROVED IF/THEN/ELSE/OTHERWISE Syntax (and, SEMANTICS)

[George Hovey-2]

Tom,
Re

"Instead just let me say that I've always used DO..END everywhere, all the time"

I must agree that, as a language solution is unlikely, this is best and is what I will continue to do.  Will newbies have to discover it on their own, after becoming "sadder but wiser?"  Will the next TNRL advise it?   Will there be yet another option, "CompulsoryDoEndInIFs" to discourage removing it from working code when it brackets a single statement?  [All questions are rhetorical.]
George

On Fri, Nov 18, 2011 at 10:31 PM, Tom Maynard <[hidden email]> wrote:

On 11/18/2011 8:38 PM, Bill Fenlason wrote:

Isn't a simple DO ... END easier than adding something to each of the included instructions?

I'm not a language policeman, nor do I play one on TV, so I'm not going to come down hard on this issue.  Instead just let me say that I've always used DO..END everywhere, all the time.  This was (mostly) driven by the maintenance issues already voiced here, and never was, nor never caused a problem.

Typing DO..END is simpler, faster, more convenient, and certainly more "human(e)"  than curly braces ... not to mention more legible.  Will Perl ever run on the JVM?  I don't think so, and neither does Larry Wall.  TARWTDI (There's A [Right, Rexx] Way To Do It]  (Unfortunately rather difficult to pronounce.]

I'm not even going to comment on the indentation-is-a-block issue.  'Nuff said.

I don't have any issue with "solutions" that (A) don't break existing code, and (B) allow others to code in their own style.  Kermit's suggestion passes this test, for example.

So I guess this is a +1 for leaving things alone, and a +0 (that's a non-negative, or "meh") for backward-compatible changes (aka "enhancements").

Tom.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Please pardon my preamble here - it is relevant. As far as changes to NetRexx go, I am probably a moderate, somewhere in between those who want to add any feature they have ever seen in any computer language and those who don't want any changes, even to fix obvious problems. I follow this guideline: Don't make any changes to NetRexx unless there is a very clear and significant improvement, whether fixing a "broken behavior" type problem or adding a feature to improve Java interoperability or whatever. That is why I have not yet decided if this item is worth opening a change issue on Kenai or not. But here is an interesting quote that I found in TNRL: "Programming languages invariably need to evolve over time as the needs and expectations of their users change".

This particular issue is not a big deal to me especially since one easy fix, as others have pointed out, is to always use explicit DO...END blocks when grouping instructions thus ignoring the language inconsistencies. In fact, another fix might be to change NetRexx to disallow the implied DO groups and always force explicit grouping (of course that could break existing code!) for more consistency. That said, the SELECT instruction is the one NetRexx instruction that violates the basic NetRexx principle of "least astonishment" for me and always forces me to look it up before I use it - Why do I need an explicit DO...END group to do anything significant WHEN I have a matching condition but don't need the explicit DO...END to handle the non-matching case (OTHERWISE)?

I have added some comments to the discussion below:

On 11/19/2011 3:30 AM, Mike Cowlishaw wrote:

Two separate questions, here:

PS: If I remember to open an issue for this, I am also going to request that the OTHERWISE construct be made consistently optional instead of the "maybe required, maybe not" that it has now. There should be an automatic default of "OTHERWISE NOP" if an otherwise is not present in a SELECT. 

 

This would remove an important safeguard .. where the programmer thinks he or she has covered all the cases in the WHEN clauses but in fact has not (often because a new possibility was added at a later date somewhere earlier in the code).     'OTHERWISE NOP' is a good indication that the programmer explicitly wants to 'throw away' unrecognised cases.   The absense of an OTHERWISE, similarly, is a good indication that the programmer has intended to cover all valid cases.

I view this from the reverse logic - the absence of an OTHERWISE indicates that the programmer does not want to do anything with non-matching cases. The unstated implication of your logic is that it is better to issue a misleading "NoOtherwiseException" at runtime which implies a program coding error rather than making the programmer explicitly handle errors with a meaningful message via something like "OTHERWISE SAY 'unexpected condition error 1234' " in his code. Perhaps this is just a personal preference but for me at least the "OTHERWISE NOP" is the more common case and thus should be the default behavior.

 

 Since the compiler currently disallows multiple instructions in a WHEN construct, no current programs have them so it would not hurt anything to enhance SELECT to allow multiple instructions in the WHEN construct (ie an implicit DO...END block/group).  

 

It would hurt by adding to complexity -- now two ways for writing the same thing (also, as Bill I think pointed out) it removes the similarity between IF and WHEN.  This, I fear, would make IF more confusing, because IF would still require a DO...END if more that one statement were to be encompassed whereas WHEN would not.

Since you can already use an implicit or an explicit DO...END in the OTHERWISE/CATCH/FINALLY sections of SELECT, I do not see why it would add complexity to do it for WHEN also. As for comparing IF to SELECT, the internal inconsistency in SELECT is far more confusing to me than any differences between IF and SELECT might be since they are completely different instructions.

 

 This would make WHEN consistent with OTHERWISE, CATCH, and FINALLY which already allow multiple instructions. (And I might even be able to use SELECT without looking up the documentation every time to see where I need a DO...END group or not!) 

 

I have some sympathy with that :-).  There was much discussion on this back in 1979/1980 -- there are lots of options to consider.  If DO-END was not specified then execution could either 'drop through' to the second statement (and continue to the next WHEN).   In general people wanted a way to execute clauses before WHENs (although this was never formalized).  For example:

 

  select label foo

    when a=0 then do

      whatever

      ...

      end

    b=b+1             -- executed whenever a\=0

    when a>0 then do

      whatever

      end

    c=c-1             -- executed whenever a<0

    when c<0 then do

      ....

      end

    ... etc. ...

    end foo

 

Note that to be fully consistent, we also need to make the "THEN" part of the WHEN construct optional when a semi-colon or line end precedes it. These changes would allow code like the following example program (without breaking any existing code!):  [snip]

 

One really should make it optional for IF, too, in that case:

 

  if a=0

    say 'A is zero'

 

but again that removes a useful deliberate redundancy/check; where (for example) someone forgot a continuation:

 

  if  abc

    def = 'ABC DEF'

    say 'whatever'

 

so .. a lot more 'ambiguous' code would be accepted and do weird things, whereas Rexx and NetRexx try to protect against typos by requiring (relatively minimal, compared to other languages) redundancy.   There's a tradeoff between redundancy and 'let everything work'.   Too much redundancy (as in Java) is tedious.  Too little and too much programmer time is wasted (cf. regular expressions).

No comment here - it does not matter to me one way or the other. I am still going to have to debug occasional errors no matter what!

Does anyone see any problem with this approach?
 

Remember that the DO-END is not needed, now, when only one statement follows the WHEN...THEN, so another interpretation of your proposal could be done now, like the example above: 

select label foo
  when a=0 then whatever
  b=b+1 -- executed whenever a\=0
  when a>0 then 
    whatever
  c=c-1 -- executed whenever a<0
  when c<0 then do
  ... etc. ...
    
In short .. there are lots of things that one can do to SELECT that add function (especially related to the CASE form); that would seem
more valuable than just adding a variation which adds no function and reduces redundancy?
Mike 

I see the value of the non-match enhancement you propose above but the syntax shown is very confusing.
In this case, if you want to handle match/non-match logic in the WHEN construct, it really does need to use the same syntax as the IF statement to avoid confusion!:

select label foo
  when a=0 then whatever
           else b=b+1 -- executed whenever a\=0
  when a>0 then 
    whatever
   else
    c=c-1 -- executed whenever a<0
  when c<0 then do
  ... etc. ...

-- Kermit

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

Kermit, thanks for the detailed thoughts.  Also thanks to Dave Woodman for the pointer for 'Outlook bar breaking'.

---

Please pardon my preamble here - it is relevant. As far as changes to NetRexx go, I am probably a moderate, somewhere in between those who want to add any feature they have ever seen in any computer language and those who don't want any changes, even to fix obvious problems. I follow this guideline: Don't make any changes to NetRexx unless there is a very clear and significant improvement, whether fixing a "broken behavior" type problem or adding a feature to improve Java interoperability or whatever. That is why I have not yet decided if this item is worth opening a change issue on Kenai or not. But here is an interesting quote that I found in TNRL: "Programming languages invariably need to evolve over time as the needs and expectations of their users change". 

Absolutely.  One has to be a bit careful over the definition of 'user', however -- for the Rexx languages I've always tried to design for the fallible 'average' user rather than the skilled rarely-makes-a-mistake developer.  (In contrast to systems and assembler languages I've designed, where programmer and program efficiency are paramount).

This particular issue is not a big deal to me especially since one easy fix, as others have pointed out, is to always use explicit DO...END blocks when grouping instructions thus ignoring the language inconsistencies. In fact, another fix might be to change NetRexx to disallow the implied DO groups and always force explicit grouping (of course that could break existing code!) for more consistency. That said, the SELECT instruction is the one NetRexx instruction that violates the basic NetRexx principle of "least astonishment" for me and always forces me to look it up before I use it - Why do I need an explicit DO...END group to do anything significant WHEN I have a matching condition but don't need the explicit DO...END to handle the non-matching case (OTHERWISE)?  

As it happens, I argued (for Rexx) that OTHERWISE should require DO...END for exactly the reason you suggest, but was outvoted by the users :-).   However, with hindsight -- and perhaps more so for NetRexx -- it seems OK, because really one can think of OTHERWISE as just a special case of CATCH ... a shorthand for 'CATCH NoOtherwiseException;' (which should have had a better name, perhaps -- "CaseNotHandledException" or something like that).

 

Now, I agree that one could argue that the WHENs could be considered some special type of CATCH-like thing, too, and could be 'precompiled' in many cases (especially when CASE is used and the cases are constants).  But in general they are a cascade of IF a THEN b ELSE IF c THEN d ELSE IF e THEN ... [etc.] .. which is really a different sort of animal -- a sequential flow of executed expressions and tests.   I think making WHEN clauses look like CASE statements in C or Java is going to be confusing to anyone coming from those languages, because in C or Java they would drop through to the next CASE (WHEN in NetRexx) -- but I think you are proposing that on reaching the next WHEN control would transfer to the end of the SELECT.

 

I'm also uncomfortable with the idea that THEN becomes 'optional'.  Sometimes it could be there, and sometimes not.  That will be confusing to readers, and once the confusion is there then it will affect the writing of IF constructs, too, and cause confusion there.   In other words .. a change that seems to be just a tweak on SELECT has a wider impact that needs to be considered part of the change: making THEN optional on WHEN means one really ought to make it optional on IF, too -- but does that mean that when THEN is omitted after IF the IF can be followed by a number of statements that are considered part of the "then" instructionlist, ended by the next IF?  If not, then we've introduced another inconsistency. 

 
I have added some comments to the discussion below:   (ditto) 
 

 
On 11/19/2011 3:30 AM, Mike Cowlishaw wrote:

Two separate questions, here:

PS: If I remember to open an issue for this, I am also going to request that the OTHERWISE construct be made consistently optional instead of the "maybe required, maybe not" that it has now. There should be an automatic default of "OTHERWISE NOP" if an otherwise is not present in a SELECT. 

 

This would remove an important safeguard .. where the programmer thinks he or she has covered all the cases in the WHEN clauses but in fact has not (often because a new possibility was added at a later date somewhere earlier in the code).     'OTHERWISE NOP' is a good indication that the programmer explicitly wants to 'throw away' unrecognised cases.   The absense of an OTHERWISE, similarly, is a good indication that the programmer has intended to cover all valid cases.

I view this from the reverse logic - the absence of an OTHERWISE indicates that the programmer does not want to do anything with non-matching cases. The unstated implication of your logic is that it is better to issue a misleading "NoOtherwiseException" at runtime which implies a program coding error rather than making the programmer explicitly handle errors with a meaningful message via something like "OTHERWISE SAY 'unexpected condition error 1234' " in his code. Perhaps this is just a personal preference but for me at least the "OTHERWISE NOP" is the more common case and thus should be the default behavior. 
 

Yes, partly a taste issue (although if it's the more common cose I wonder if writing IF ... ELSE IF ... ELSE IF ... constructs would suit you better).  But I am really coming at it from a different direction.  It's a very common mistake to accidentally not cover all the cases in a SELECT when one intended to cover them all explicitly, for example off-by-one errors, or forgetting that sometimes numbers can have negative values, or some comparison fails due to binary/decimal conversions.  This kind of error is very hard to localise, because reading the code won't show it up and what is happening is that some  code doesn't get executed when it appears that it should.  The NoOtherwiseException immediately draws attention to exactly the cause and place of the problem.

 

This is much more of a problem with SELECT than for IF beacuse the latter is a simple yes/no decision in one place and is more easily scrutinized, whereas by nature SELECTs can have many different and complicated, often interacting, tests that can extend over some length of code.

 

Similarly, the current behaviour lets one deliberately omit the OTHERWISE, knowing that if anything changes and the cases covered are no longer sufficient one will find out about it.

 

 Since the compiler currently disallows multiple instructions in a WHEN construct, no current programs have them so it would not hurt anything to enhance SELECT to allow multiple instructions in the WHEN construct (ie an implicit DO...END block/group).  

 

It would hurt by adding to complexity -- now two ways for writing the same thing (also, as Bill I think pointed out) it removes the similarity between IF and WHEN.  This, I fear, would make IF more confusing, because IF would still require a DO...END if more that one statement were to be encompassed whereas WHEN would not.

Since you can already use an implicit or an explicit DO...END in the OTHERWISE/CATCH/FINALLY sections of SELECT, I do not see why it would add complexity to do it for WHEN also. As for comparing IF to SELECT, the internal inconsistency in SELECT is far more confusing to me than any differences between IF and SELECT might be since they are completely different instructions. 

[See introductory paragraphs.]

 

 This would make WHEN consistent with OTHERWISE, CATCH, and FINALLY which already allow multiple instructions. (And I might even be able to use SELECT without looking up the documentation every time to see where I need a DO...END group or not!) 

 

I have some sympathy with that :-).  There was much discussion on this back in 1979/1980 -- there are lots of options to consider.  If DO-END was not specified then execution could either 'drop through' to the second statement (and continue to the next WHEN).   In general people wanted a way to execute clauses before WHENs (although this was never formalized).  For example:

 

  select label foo

    when a=0 then do

      whatever

      ...

      end

    b=b+1             -- executed whenever a\=0

    when a>0 then do

      whatever

      end

    c=c-1             -- executed whenever a<0

    when c<0 then do

      ....

      end

    ... etc. ...

    end foo

 

Note that to be fully consistent, we also need to make the "THEN" part of the WHEN construct optional when a semi-colon or line end precedes it. These changes would allow code like the following example program (without breaking any existing code!):  [snip]

 

One really should make it optional for IF, too, in that case:

 

  if a=0

    say 'A is zero'

 

but again that removes a useful deliberate redundancy/check; where (for example) someone forgot a continuation:

 

  if  abc

    def = 'ABC DEF'

    say 'whatever'

 

so .. a lot more 'ambiguous' code would be accepted and do weird things, whereas Rexx and NetRexx try to protect against typos by requiring (relatively minimal, compared to other languages) redundancy.   There's a tradeoff between redundancy and 'let everything work'.   Too much redundancy (as in Java) is tedious.  Too little and too much programmer time is wasted (cf. regular expressions).

No comment here - it does not matter to me one way or the other. I am still going to have to debug occasional errors no matter what! 

I'm claiming that by removing redundancy the compiler/interpreter can do less checking for you and hence those errors will be more common and more subtle than currently.  Typos that are immediately picked up by the current compiler would become valid (if weird) code under the new rules. 

Does anyone see any problem with this approach?
 

Remember that the DO-END is not needed, now, when only one statement follows the WHEN...THEN, so another interpretation of your proposal could be done now, like the example above: 

select label foo
  when a=0 then whatever
  b=b+1 -- executed whenever a\=0
  when a>0 then 
    whatever
  c=c-1 -- executed whenever a<0
  when c<0 then do
  ... etc. ...
    
In short .. there are lots of things that one can do to SELECT that add function (especially related to the CASE form); that would seem
more valuable than just adding a variation which adds no function and reduces redundancy?
Mike 

I see the value of the non-match enhancement you propose above but the syntax shown is very confusing.  

Yes, I agree; that was what I was trying to illustrate.  The syntax above in the longer example code is much clearer, I think -- and does add useful new function.

 
In this case, if you want to handle match/non-match logic in the WHEN construct, it really does need to use the same syntax as the IF statement to avoid confusion!:

select label foo
  when a=0 then whatever
           else b=b+1 -- executed whenever a\=0
  when a>0 then 
    whatever
   else
    c=c-1 -- executed whenever a<0
  when c<0 then do
  ... etc. ... 

That certainly makes the point that WHEN is more like an IF than a CATCH :-).   But there is a difference .. at the end of the THEN instruction (e.g., your first 'whatever') control passes to the end of the loop -- so there's really no need for an ELSE clause.   It's really:

 

  if a=0 then do; whatever; signal end_of_select; end 

         -- where there's a sort of implied CATCH end_of_select just before FINALLY or END

 b=b+1   -- this is  executed only when a\=0

 

and one wouldn't normally use an ELSE there.

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Mike -

Thanks for your comments. You have convinced me not to open an issue for this item. That is not because I agree with your arguments, but in order to "choose my battles" because there are critical problems to fix (like the method resolution bugs), whereas the SELECT inconsistency is at worst a minor annoyance and I seldom use the select instruction. (I am still trying to figure out whether I seldom use it because the inconsistency makes it hard to remember how or if it is hard to remember how it works because I seldom use it! ;-) The only argument for the status quo that makes sense to me is that it matches classic and object Rexx behavior and that is important because I suspect that most if not all NetRexx newbies actually come from the Rexx groups.

And I think I am beginning to see why there is so much resistance to change here and where our difference in philosophy arises. From your comments it appears that you and possibly others view SELECT as an extended version of the IF statement which makes cascading "IF...THEN...ELSE IF...THEN...ELSE IF...THEN..." constructs easier to express, whereas I (and possibly others) view it as a completely separate instruction from IF which has no relationship except that it is a conditional construct as is LOOP.  From my view, the THEN keyword in the WHEN construct adds nothing while from your view it connects it conceptually to the IF...THEN statement. Unfortunately, if I were to adopt your view it would only confuse me more because the IF statement has both THEN and ELSE keywords while the WHEN construct only has a THEN keyword which is still a puzzling inconsistency to me.

If I were to design a SELECT instruction based on the extended IF view, it would probably look something like this:

SELECT

  IF ..... THEN instruction

    ELSE instruction

  IF ..... THEN instruction

    ELSE instruction

  OTHERWISE instruction

END

For now, lets agree to disagree!

-- Kermit

PS: Of course, there is another option too! NetRexx could add another completely different conditional construct somewhat like this:

CHECKCONDITION

  ONCONDITION expression

    instructionlist

  ONCONDITION expression

    instructionlist

  ONOTHERCONDITIONS

    instructionlist

END -- CHECK

On 11/20/2011 4:03 AM, Mike Cowlishaw wrote:

Kermit, thanks for the detailed thoughts.  Also thanks to Dave Woodman for the pointer for 'Outlook bar breaking'.

---

Please pardon my preamble here - it is relevant. As far as changes to NetRexx go, I am probably a moderate, somewhere in between those who want to add any feature they have ever seen in any computer language and those who don't want any changes, even to fix obvious problems. I follow this guideline: Don't make any changes to NetRexx unless there is a very clear and significant improvement, whether fixing a "broken behavior" type problem or adding a feature to improve Java interoperability or whatever. That is why I have not yet decided if this item is worth opening a change issue on Kenai or not. But here is an interesting quote that I found in TNRL: "Programming languages invariably need to evolve over time as the needs and expectations of their users change". 

Absolutely.  One has to be a bit careful over the definition of 'user', however -- for the Rexx languages I've always tried to design for the fallible 'average' user rather than the skilled rarely-makes-a-mistake developer.  (In contrast to systems and assembler languages I've designed, where programmer and program efficiency are paramount).

This particular issue is not a big deal to me especially since one easy fix, as others have pointed out, is to always use explicit DO...END blocks when grouping instructions thus ignoring the language inconsistencies. In fact, another fix might be to change NetRexx to disallow the implied DO groups and always force explicit grouping (of course that could break existing code!) for more consistency. That said, the SELECT instruction is the one NetRexx instruction that violates the basic NetRexx principle of "least astonishment" for me and always forces me to look it up before I use it - Why do I need an explicit DO...END group to do anything significant WHEN I have a matching condition but don't need the explicit DO...END to handle the non-matching case (OTHERWISE)?  

As it happens, I argued (for Rexx) that OTHERWISE should require DO...END for exactly the reason you suggest, but was outvoted by the users :-).   However, with hindsight -- and perhaps more so for NetRexx -- it seems OK, because really one can think of OTHERWISE as just a special case of CATCH ... a shorthand for 'CATCH NoOtherwiseException;' (which should have had a better name, perhaps -- "CaseNotHandledException" or something like that).

 

Now, I agree that one could argue that the WHENs could be considered some special type of CATCH-like thing, too, and could be 'precompiled' in many cases (especially when CASE is used and the cases are constants).  But in general they are a cascade of IF a THEN b ELSE IF c THEN d ELSE IF e THEN ... [etc.] .. which is really a different sort of animal -- a sequential flow of executed expressions and tests.   I think making WHEN clauses look like CASE statements in C or Java is going to be confusing to anyone coming from those languages, because in C or Java they would drop through to the next CASE (WHEN in NetRexx) -- but I think you are proposing that on reaching the next WHEN control would transfer to the end of the SELECT.

 

I'm also uncomfortable with the idea that THEN becomes 'optional'.  Sometimes it could be there, and sometimes not.  That will be confusing to readers, and once the confusion is there then it will affect the writing of IF constructs, too, and cause confusion there.   In other words .. a change that seems to be just a tweak on SELECT has a wider impact that needs to be considered part of the change: making THEN optional on WHEN means one really ought to make it optional on IF, too -- but does that mean that when THEN is omitted after IF the IF can be followed by a number of statements that are considered part of the "then" instructionlist, ended by the next IF?  If not, then we've introduced another inconsistency. 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hello Kermit, *and all*
   may I please UNDERLINE and SUPPORT both of your paragraphs below.

As I alread tried to point out, the resolution would be to give the currently *optional semicolon* (which might be actually a carriage return) in the
NetRexx Syntax of the IF, ELSE, WHEN, and OTHERWISE clauses a *semantic meaning*, i.e:

-- when the SEMICOLON (and of line) is NOT present, a single instruction follows
-- when the semicolon (or carriage return) IS present, a sequence of instractions follows.

This will instantly allow to have now need for the DO ...  END after the WHEN clause, and also at the IF and ELSE clauses, with one addition needed
only: END IF (I would personally spell it this way... :-) to end a strucutered.IF statement.

I already did propose, long tie ago, to allow the END statement to be followed by a keyword, e.g.

END SELECT
END IF

etc.

Before confusing you all too much: of course the END label must be looked up first, and then the matching keyword should be looked up.

This might greatly enhance the readability of heavily nested structures, as well.

Greetings from Vienna,
Thomas.

PS: And yes, please, NetRexx should keep to be an evolving language, not a frozen one... :-)
=================================================================================================


Am 19.11.2011 21:48, schrieb Kermit Kiser:

Please pardon my preamble here - it is relevant. As far as changes to NetRexx go, I am probably a moderate, somewhere in between those who want to add any feature they have ever seen in any computer language and those who don't want any changes, even to fix obvious problems. I follow this guideline: Don't make any changes to NetRexx unless there is a very clear and significant improvement, whether fixing a "broken behavior" type problem or adding a feature to improve Java interoperability or whatever. That is why I have not yet decided if this item is worth opening a change issue on Kenai or not. But here is an interesting quote that I found in TNRL: "Programming languages invariably need to evolve over time as the needs and expectations of their users change".

This particular issue is not a big deal to me especially since one easy fix, as others have pointed out, is to always use explicit DO...END blocks when grouping instructions thus ignoring the language inconsistencies. In fact, another fix might be to change NetRexx to disallow the implied DO groups and always force explicit grouping (of course that could break existing code!) for more consistency. That said, the SELECT instruction is the one NetRexx instruction that violates the basic NetRexx principle of "least astonishment" for me and always forces me to look it up before I use it - Why do I need an explicit DO...END group to do anything significant WHEN I have a matching condition but don't need the explicit DO...END to handle the non-matching case (OTHERWISE)?

I have added some comments to the discussion below:

On 11/19/2011 3:30 AM, Mike Cowlishaw wrote:

Two separate questions, here:

PS: If I remember to open an issue for this, I am also going to request that the OTHERWISE construct be made consistently optional instead of the "maybe required, maybe not" that it has now. There should be an automatic default of "OTHERWISE NOP" if an otherwise is not present in a SELECT. 

 

This would remove an important safeguard .. where the programmer thinks he or she has covered all the cases in the WHEN clauses but in fact has not (often because a new possibility was added at a later date somewhere earlier in the code).     'OTHERWISE NOP' is a good indication that the programmer explicitly wants to 'throw away' unrecognised cases.   The absense of an OTHERWISE, similarly, is a good indication that the programmer has intended to cover all valid cases.

I view this from the reverse logic - the absence of an OTHERWISE indicates that the programmer does not want to do anything with non-matching cases. The unstated implication of your logic is that it is better to issue a misleading "NoOtherwiseException" at runtime which implies a program coding error rather than making the programmer explicitly handle errors with a meaningful message via something like "OTHERWISE SAY 'unexpected condition error 1234' " in his code. Perhaps this is just a personal preference but for me at least the "OTHERWISE NOP" is the more common case and thus should be the default behavior.

 

 Since the compiler currently disallows multiple instructions in a WHEN construct, no current programs have them so it would not hurt anything to enhance SELECT to allow multiple instructions in the WHEN construct (ie an implicit DO...END block/group).  

 

It would hurt by adding to complexity -- now two ways for writing the same thing (also, as Bill I think pointed out) it removes the similarity between IF and WHEN.  This, I fear, would make IF more confusing, because IF would still require a DO...END if more that one statement were to be encompassed whereas WHEN would not.

Since you can already use an implicit or an explicit DO...END in the OTHERWISE/CATCH/FINALLY sections of SELECT, I do not see why it would add complexity to do it for WHEN also. As for comparing IF to SELECT, the internal inconsistency in SELECT is far more confusing to me than any differences between IF and SELECT might be since they are completely different instructions.

 

 This would make WHEN consistent with OTHERWISE, CATCH, and FINALLY which already allow multiple instructions. (And I might even be able to use SELECT without looking up the documentation every time to see where I need a DO...END group or not!) 

 

I have some sympathy with that :-).  There was much discussion on this back in 1979/1980 -- there are lots of options to consider.  If DO-END was not specified then execution could either 'drop through' to the second statement (and continue to the next WHEN).   In general people wanted a way to execute clauses before WHENs (although this was never formalized).  For example:

 

  select label foo

    when a=0 then do

      whatever

      ...

      end

    b=b+1             -- executed whenever a\=0

    when a>0 then do

      whatever

      end

    c=c-1             -- executed whenever a<0

    when c<0 then do

      ....

      end

    ... etc. ...

    end foo

 

Note that to be fully consistent, we also need to make the "THEN" part of the WHEN construct optional when a semi-colon or line end precedes it. These changes would allow code like the following example program (without breaking any existing code!):  [snip]

 

One really should make it optional for IF, too, in that case:

 

  if a=0

    say 'A is zero'

 

but again that removes a useful deliberate redundancy/check; where (for example) someone forgot a continuation:

 

  if  abc

    def = 'ABC DEF'

    say 'whatever'

 

so .. a lot more 'ambiguous' code would be accepted and do weird things, whereas Rexx and NetRexx try to protect against typos by requiring (relatively minimal, compared to other languages) redundancy.   There's a tradeoff between redundancy and 'let everything work'.   Too much redundancy (as in Java) is tedious.  Too little and too much programmer time is wasted (cf. regular expressions).

No comment here - it does not matter to me one way or the other. I am still going to have to debug occasional errors no matter what!

Does anyone see any problem with this approach?
 

Remember that the DO-END is not needed, now, when only one statement follows the WHEN...THEN, so another interpretation of your proposal could be done now, like the example above: 

select label foo
  when a=0 then whatever
  b=b+1 -- executed whenever a\=0
  when a>0 then 
    whatever
  c=c-1 -- executed whenever a<0
  when c<0 then do
  ... etc. ...
    
In short .. there are lots of things that one can do to SELECT that add function (especially related to the CASE form); that would seem
more valuable than just adding a variation which adds no function and reduces redundancy?
Mike 

I see the value of the non-match enhancement you propose above but the syntax shown is very confusing.
In this case, if you want to handle match/non-match logic in the WHEN construct, it really does need to use the same syntax as the IF statement to avoid confusion!:

select label foo
  when a=0 then whatever
           else b=b+1 -- executed whenever a\=0
  when a>0 then 
    whatever
   else
    c=c-1 -- executed whenever a<0
  when c<0 then do
  ... etc. ...

-- Kermit

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Hi Kermit,
Just a couple of comments.  Re

"I suspect that most if not all NetRexx newbies actually come from the Rexx groups"

This is what we must work to change.  The constant bowing to Rexx suggests that we are preaching to the choir.  If NetRexx is just a plaything for IBM retirees its future is bleak.  We should be working to assure that many newbies come from other languages, and especially Java, because of the special contribution they can make.  Rexx may be only a word to those people.  Our primary pitch should be "NetRexx = Humanistic Java."

Re

CHECKCONDITION

  ONCONDITION expression

    instructionlist

  ONCONDITION expression

    instructionlist

  ONOTHERCONDITIONS

    instructionlist

END -- CHECK

You are well on the way to inventing the Fortran 77 Block IF statement, except that the efficacy of that construct has been established through more than 30 years of experience.  This is a step in the right direction :) .   Your key insight, in my view, is the realization that this construct need not impact NetRexx's current IF statement, if new keywords are chosen, eg BlockIf, BlockElseIf, BlockElse, BlockEnd.  Of course this should have the same adornments as the current IF (Label, Protect, exception handling, etc).  Why can't we learn from other languages?  Must everything be Invented Here?

On Sun, Nov 20, 2011 at 7:48 PM, Kermit Kiser <[hidden email]> wrote:

Mike -

Thanks for your comments. You have convinced me not to open an issue for this item. That is not because I agree with your arguments, but in order to "choose my battles" because there are critical problems to fix (like the method resolution bugs), whereas the SELECT inconsistency is at worst a minor annoyance and I seldom use the select instruction. (I am still trying to figure out whether I seldom use it because the inconsistency makes it hard to remember how or if it is hard to remember how it works because I seldom use it! ;-) The only argument for the status quo that makes sense to me is that it matches classic and object Rexx behavior and that is important because I suspect that most if not all NetRexx newbies actually come from the Rexx groups.

And I think I am beginning to see why there is so much resistance to change here and where our difference in philosophy arises. From your comments it appears that you and possibly others view SELECT as an extended version of the IF statement which makes cascading "IF...THEN...ELSE IF...THEN...ELSE IF...THEN..." constructs easier to express, whereas I (and possibly others) view it as a completely separate instruction from IF which has no relationship except that it is a conditional construct as is LOOP.  From my view, the THEN keyword in the WHEN construct adds nothing while from your view it connects it conceptually to the IF...THEN statement. Unfortunately, if I were to adopt your view it would only confuse me more because the IF statement has both THEN and ELSE keywords while the WHEN construct only has a THEN keyword which is still a puzzling inconsistency to me.

If I were to design a SELECT instruction based on the extended IF view, it would probably look something like this:

SELECT

  IF ..... THEN instruction

    ELSE instruction

  IF ..... THEN instruction

    ELSE instruction

  OTHERWISE instruction

END

For now, lets agree to disagree!

-- Kermit

PS: Of course, there is another option too! NetRexx could add another completely different conditional construct somewhat like this:

CHECKCONDITION

  ONCONDITION expression

    instructionlist

  ONCONDITION expression

    instructionlist

  ONOTHERCONDITIONS

    instructionlist

END -- CHECK

On 11/20/2011 4:03 AM, Mike Cowlishaw wrote:

Kermit, thanks for the detailed thoughts.  Also thanks to Dave Woodman for the pointer for 'Outlook bar breaking'.

---

Please pardon my preamble here - it is relevant. As far as changes to NetRexx go, I am probably a moderate, somewhere in between those who want to add any feature they have ever seen in any computer language and those who don't want any changes, even to fix obvious problems. I follow this guideline: Don't make any changes to NetRexx unless there is a very clear and significant improvement, whether fixing a "broken behavior" type problem or adding a feature to improve Java interoperability or whatever. That is why I have not yet decided if this item is worth opening a change issue on Kenai or not. But here is an interesting quote that I found in TNRL: "Programming languages invariably need to evolve over time as the needs and expectations of their users change". 

Absolutely.  One has to be a bit careful over the definition of 'user', however -- for the Rexx languages I've always tried to design for the fallible 'average' user rather than the skilled rarely-makes-a-mistake developer.  (In contrast to systems and assembler languages I've designed, where programmer and program efficiency are paramount).

This particular issue is not a big deal to me especially since one easy fix, as others have pointed out, is to always use explicit DO...END blocks when grouping instructions thus ignoring the language inconsistencies. In fact, another fix might be to change NetRexx to disallow the implied DO groups and always force explicit grouping (of course that could break existing code!) for more consistency. That said, the SELECT instruction is the one NetRexx instruction that violates the basic NetRexx principle of "least astonishment" for me and always forces me to look it up before I use it - Why do I need an explicit DO...END group to do anything significant WHEN I have a matching condition but don't need the explicit DO...END to handle the non-matching case (OTHERWISE)?  

As it happens, I argued (for Rexx) that OTHERWISE should require DO...END for exactly the reason you suggest, but was outvoted by the users :-).   However, with hindsight -- and perhaps more so for NetRexx -- it seems OK, because really one can think of OTHERWISE as just a special case of CATCH ... a shorthand for 'CATCH NoOtherwiseException;' (which should have had a better name, perhaps -- "CaseNotHandledException" or something like that).

 

Now, I agree that one could argue that the WHENs could be considered some special type of CATCH-like thing, too, and could be 'precompiled' in many cases (especially when CASE is used and the cases are constants).  But in general they are a cascade of IF a THEN b ELSE IF c THEN d ELSE IF e THEN ... [etc.] .. which is really a different sort of animal -- a sequential flow of executed expressions and tests.   I think making WHEN clauses look like CASE statements in C or Java is going to be confusing to anyone coming from those languages, because in C or Java they would drop through to the next CASE (WHEN in NetRexx) -- but I think you are proposing that on reaching the next WHEN control would transfer to the end of the SELECT.

 

I'm also uncomfortable with the idea that THEN becomes 'optional'.  Sometimes it could be there, and sometimes not.  That will be confusing to readers, and once the confusion is there then it will affect the writing of IF constructs, too, and cause confusion there.   In other words .. a change that seems to be just a tweak on SELECT has a wider impact that needs to be considered part of the change: making THEN optional on WHEN means one really ought to make it optional on IF, too -- but does that mean that when THEN is omitted after IF the IF can be followed by a number of statements that are considered part of the "then" instructionlist, ended by the next IF?  If not, then we've introduced another inconsistency. 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

Note that in NetRexx, the following are all equivalent:

IF a = 1 THEN x = 2
IF a = 1 ; THEN x = 2
IF a = 1 THEN ; x = 2
IF a = 1 THEN x = 2 ; 
IF a = 1 ; THEN ; x = 2
IF a = 1 ; THEN x = 2 ; 
IF a = 1 THEN ; x = 2 ; 
IF a = 1 ; THEN ; x = 2 ; 

and the 8 variations (for optional semicolons) for each of the following:

IF a = 1 THEN
   x = 2

IF a = 1
   THEN x = 2

IF a = 1
THEN
   x = 2

Similarly, the following are equivalent:

IF a = 1 THEN x = 2 ELSE y = 2

IF a = 1 ;
THEN ;
   x = 2 ;
ELSE ;
   y = 2 ;

as are all of the other arrangements on from 1 to 5 lines.

Each element may occur on any line, and each is optionally followed by a semicolon.  I count a total of 128 arrangements of the 5 elements in an IF-THEN-ELSE construct.

In all of these examples, any of the assignment statements may be replaced by a DO - END, LOOP or SELECT instruction.  In practice, there is often only a single instruction to be executed, and the complex instruction is not necessary.

My point is that the independence of the placement of the parts of an IF construct is fundamental in NetRexx (and Rexx), and it cannot be limited without breakage.

Attempting to introduce some form of the FORTRAN block IF will most likely not work in all of those situations.  I would be more open to the idea of some kind of block IF construct if someone can show me how it would be compatible with all of the current (160) forms of the existing NetRexx IF construct.

As George points out, the only viable approach would be the introduction of a new construct with new keywords, like BLOCKIF, ELSEIF and ENDIF.  But

BLOCKIF a = 1 THEN
   x = 2
ELSE
   y = 2
ENDIF

is equivalent to

IF a = 1 THEN DO
   x = 2
   END
ELSE DO
   y = 2
   END

The BLOCKIF structure is redundant, and with the goal of keeping the language simple, I think unnecessary. 

Adding a new instruction to avoid using DO-END is not justified, in my opinion.

Bill


On 11/21/2011 9:23 AM, George Hovey wrote:
    ...

You are well on the way to inventing the Fortran 77 Block IF statement, except that the efficacy of that construct has been established through more than 30 years of experience.  This is a step in the right direction :) .   Your key insight, in my view, is the realization that this construct need not impact NetRexx's current IF statement, if new keywords are chosen, eg BlockIf, BlockElseIf, BlockElse, BlockEnd.  Of course this should have the same adornments as the current IF (Label, Protect, exception handling, etc).  Why can't we learn from other languages?  Must everything be Invented Here?

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[christel.u.w.pachl christel.u.w.pachl]

not really´!!!
The ELSE is NOT recognized as condition terminator:
/* REXX */  Trace R              
a=1                              
x=2                              
y=3                              
IF a = 1 THEN x = 2 ELSE y = 2    
Say x                            
Say y                            
      2 *-* a=1                
        >>>   "1"              
      3 *-* x=2                
        >>>   "2"              
      4 *-* y=3                
        >>>   "3"              
      5 *-* IF a = 1            
        >>>   "1"              
        *-*  THEN              
        *-*  x = 2 ELSE y = 2  
        >>>    "0"              
      6 *-* Say x              
        >>>   "0"              
 0                              
      7 *-* Say y              
        >>>   "3"              
 3                              
---- Bill Fenlason <[hidden email]> schrieb:
> Note that in NetRexx, the following are all equivalent:
>
> IF a = 1 THEN x = 2
> IF a = 1 ; THEN x = 2
> IF a = 1 THEN ; x = 2
> IF a = 1 THEN x = 2 ;

> IF a = 1 ; THEN ; x = 2
> IF a = 1 ; THEN x = 2 ;
> IF a = 1 THEN ; x = 2 ;
> IF a = 1 ; THEN ; x = 2 ;
>
> and the 8 variations (for optional semicolons) for each of the following:
>
> IF a = 1 THEN
>     x = 2
>
> IF a = 1
>     THEN x = 2
>
> IF a = 1
> THEN
>     x = 2
>
> Similarly, the following are equivalent:
>
> IF a = 1 THEN x = 2 ELSE y = 2
>
> IF a = 1 ;
> THEN ;
>     x = 2 ;
> ELSE ;
>     y = 2 ;
>
> as are all of the other arrangements on from 1 to 5 lines.
>
> Each element may occur on any line, and each is optionally followed by a
> semicolon.  I count a total of 128 arrangements of the 5 elements in an
> IF-THEN-ELSE construct.
>
> In all of these examples, any of the assignment statements may be
> replaced by a DO - END, LOOP or SELECT instruction.  In practice, there
> is often only a single instruction to be executed, and the complex
> instruction is not necessary.
>
> My point is that the independence of the placement of the parts of an IF
> construct is fundamental in NetRexx (and Rexx), and it cannot be limited
> without breakage.
>
> Attempting to introduce some form of the FORTRAN block IF will most
> likely not work in all of those situations.  I would be more open to the
> idea of some kind of block IF construct if someone can show me how it
> would be compatible with all of the current (160) forms of the existing
> NetRexx IF construct.
>
> As George points out, the only viable approach would be the introduction
> of a new construct with new keywords, like BLOCKIF, ELSEIF and ENDIF.  But
>
> BLOCKIF a = 1 THEN
>     x = 2
> ELSE
>     y = 2
> ENDIF
>
> is equivalent to
>
> IF a = 1 THEN DO
>     x = 2
>     END
> ELSE DO
>     y = 2
>     END
>
> The BLOCKIF structure is redundant, and with the goal of keeping the
> language simple, I think unnecessary.
>
> Adding a new instruction to avoid using DO-END is not justified, in my
> opinion.
>
> Bill
>
>
> On 11/21/2011 9:23 AM, George Hovey wrote:
>      ...
> > You are well on the way to inventing the Fortran 77 Block IF
> > statement, except that the efficacy of that construct has been
> > established through more than 30 years of experience.  This is a step
> > in the right direction :) .   Your key insight, in my view, is the
> > realization that this construct need not impact NetRexx's current IF
> > statement, if new keywords are chosen, eg BlockIf, BlockElseIf,
> > BlockElse, BlockEnd.  Of course this should have the same adornments
> > as the current IF (Label, Protect, exception handling, etc).  Why
> > can't we learn from other languages?  Must everything be Invented Here?
> >
> >

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Bill,

Re "The BLOCKIF structure is redundant, and with the goal of keeping the language simple, I think unnecessary. "

Of course IF and BLOCKIF are logically equivalent in the sense that anything expressible with one can be expressed by the other.  And a Turing machine is equivalent to a PC, but nobody wants to program a PC by describing tapes moving to and fro one symbol at a time.

Obviously, that comparison is exaggerated, but I believe that the BLOCKIF is superior to our IF in organizing a complex set of sequential binary decisions: superior, that is, from the perspective of the limitations of human cognition.  Unfortunately, I can't prove this, for several reasons.

• Almost nothing is known of factors affecting the intelligibily of programs.  [ATTENTION LANGUAGE DESIGNERS.  Have you looked at Cognitive Psychology?  Have you ever entertained for one moment the thought that something outside of the computer science curriculum might have a bearing on the usability of programming languages?]  All my conclusions are based on the study of exactly one subject, who may just be a dullard.
  
• I would like to exhibit some comparisons of the two approaches to show that BLOCKIF is clearer, but I would put our IF at an unfair disadvantage because I have never found a way, and I've tried hard, to express a complex series of nested IFs so I can understand it.  I'm often left with a complaining compiler and no clue as to where I went wrong.  [Wouldn't IF Label...End Label be a help here?]

What could be the source of this putative advantage of BLOCKIF?  Here's a guess.  There is a famous paper in cognitive psychology, "The Magic Number Seven Plus or Minus Two," saying, very roughly, that you can keep about 7 things in your head at any given time.  A large body of work says that the key to mentally handling complex relationships is to "chunk" the data:  start with the lowest level and find some way to regard small sets of relations as a single chunk, then move up the chain looking at relationships between the chunks, and naming new chunks.  [This seems closely related to the reason we analyze programs into nested functions, none of which is very long.]  I think I find BLOCKIF so mentally congenial because it gives me a ready-made chunk, so that I can immediately move to thinking about the relationship between these chunks.  Again, just a guess.

On Mon, Nov 21, 2011 at 10:53 AM, Bill Fenlason <[hidden email]> wrote:

Note that in NetRexx, the following are all equivalent:

IF a = 1 THEN x = 2
IF a = 1 ; THEN x = 2
IF a = 1 THEN ; x = 2
IF a = 1 THEN x = 2 ; 
IF a = 1 ; THEN ; x = 2
IF a = 1 ; THEN x = 2 ; 
IF a = 1 THEN ; x = 2 ; 
IF a = 1 ; THEN ; x = 2 ; 

and the 8 variations (for optional semicolons) for each of the following:

IF a = 1 THEN
   x = 2

IF a = 1
   THEN x = 2

IF a = 1
THEN
   x = 2

Similarly, the following are equivalent:

IF a = 1 THEN x = 2 ELSE y = 2

IF a = 1 ;
THEN ;
   x = 2 ;
ELSE ;
   y = 2 ;

as are all of the other arrangements on from 1 to 5 lines.

Each element may occur on any line, and each is optionally followed by a semicolon.  I count a total of 128 arrangements of the 5 elements in an IF-THEN-ELSE construct.

In all of these examples, any of the assignment statements may be replaced by a DO - END, LOOP or SELECT instruction.  In practice, there is often only a single instruction to be executed, and the complex instruction is not necessary.

My point is that the independence of the placement of the parts of an IF construct is fundamental in NetRexx (and Rexx), and it cannot be limited without breakage.

Attempting to introduce some form of the FORTRAN block IF will most likely not work in all of those situations.  I would be more open to the idea of some kind of block IF construct if someone can show me how it would be compatible with all of the current (160) forms of the existing NetRexx IF construct.

As George points out, the only viable approach would be the introduction of a new construct with new keywords, like BLOCKIF, ELSEIF and ENDIF.  But

BLOCKIF a = 1 THEN
   x = 2
ELSE
   y = 2
ENDIF

is equivalent to

IF a = 1 THEN DO
   x = 2
   END
ELSE DO
   y = 2
   END

The BLOCKIF structure is redundant, and with the goal of keeping the language simple, I think unnecessary. 

Adding a new instruction to avoid using DO-END is not justified, in my opinion.

Bill


On 11/21/2011 9:23 AM, George Hovey wrote:
    ...

You are well on the way to inventing the Fortran 77 Block IF statement, except that the efficacy of that construct has been established through more than 30 years of experience.  This is a step in the right direction :) .   Your key insight, in my view, is the realization that this construct need not impact NetRexx's current IF statement, if new keywords are chosen, eg BlockIf, BlockElseIf, BlockElse, BlockEnd.  Of course this should have the same adornments as the current IF (Label, Protect, exception handling, etc).  Why can't we learn from other languages?  Must everything be Invented Here?

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Robert L Hamilton]

I haven't been in the attic but haven't located my ALGOL manual. How was this handled in ALGOL?  Somehow, Somewhere there was a CASE ... OTHERWISE construct.

Intriguing thread; Would make an interesting article -- or maybe a Dissertation;  Thnx, Y'All;

Bob Hamilton
Richardson Texas USA

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Bob,
That brought back memories.  'Wiki Dangling Else' notes that Algo 60 used IF...THEN (which embeds the 'dangling else' problem) but Algol 68 rethought this to add END IF.

On Mon, Nov 21, 2011 at 12:45 PM, Robert Hamilton <[hidden email]> wrote:

I haven't been in the attic but haven't located my ALGOL manual. How was this handled in ALGOL?  Somehow, Somewhere there was a CASE ... OTHERWISE construct.

Intriguing thread; Would make an interesting article -- or maybe a Dissertation;  Thnx, Y'All;

Bob Hamilton
Richardson Texas USA

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Robert L Hamilton]

'course FORTRAN solved the problem w/:  GOTO . . .

Bob H
Richardson Texas USA

On Mon, Nov 21, 2011 at 12:13 PM, George Hovey <[hidden email]> wrote:

Bob,
That brought back memories.  'Wiki Dangling Else' notes that Algo 60 used IF...THEN (which embeds the 'dangling else' problem) but Algol 68 rethought this to add END IF.

On Mon, Nov 21, 2011 at 12:45 PM, Robert Hamilton <[hidden email]> wrote:

I haven't been in the attic but haven't located my ALGOL manual. How was this handled in ALGOL?  Somehow, Somewhere there was a CASE ... OTHERWISE construct.

Intriguing thread; Would make an interesting article -- or maybe a Dissertation;  Thnx, Y'All;

Bob Hamilton
Richardson Texas USA

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Bob,
Even more powerful: the Arithmetic IF (three way branch), which encourages writing truly astonishing programs.  This was a favorite of a beloved ex-boss and programmer wannabe; when he was having problems with a program, we would be very busy to avoid becoming consultants; the lion's share of his statements were numbered.

On Mon, Nov 21, 2011 at 1:44 PM, Robert Hamilton <[hidden email]> wrote:

'course FORTRAN solved the problem w/:  GOTO . . .

Bob H
Richardson Texas USA

On Mon, Nov 21, 2011 at 12:13 PM, George Hovey <[hidden email]> wrote:

Bob,
That brought back memories.  'Wiki Dangling Else' notes that Algo 60 used IF...THEN (which embeds the 'dangling else' problem) but Algol 68 rethought this to add END IF.

On Mon, Nov 21, 2011 at 12:45 PM, Robert Hamilton <[hidden email]> wrote:

I haven't been in the attic but haven't located my ALGOL manual. How was this handled in ALGOL?  Somehow, Somewhere there was a CASE ... OTHERWISE construct.

Intriguing thread; Would make an interesting article -- or maybe a Dissertation;  Thnx, Y'All;

Bob Hamilton
Richardson Texas USA

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

George,

It seems to me that all examples of a block IF, like

BLOCKIF a = 1 THEN
   x = 2
   xx = 22
ELSEIF b = 2 THEN
   y = 2
   yy = 22
ELSE
   z = 1
   zz = 11
ENDIF

can be converted to

IF a = 1 THEN DO
   x = 2
   xx = 22
   END
ELSE IF b = 2 THEN DO
   y = 2
   yy = 22
   END
ELSE DO
   z = 1
   zz = 11
   END

I think it would be useful if you had some examples, but I understand the difficulty.

From a cognitive psychology standpoint, the issue may be the mechanism by which instructions are grouped.  Some languages (e.g. NetRexx) use explicit tokens, like DO ... END or { ... }.  Others use implicit clues, like indentation or an ending assumed by the existence of a following keyword.  It's reasonable to assume that explicit grouping tokens impact the "magic number" more than does implicit grouping.

Possibly your feeling about the superiority of the FORTRAN block IF is due to the fact that most of the grouping mechanism tokens are omitted, thus reducing the "magic number"? 

I don't think there is any easy answer with regard to NetRexx.  Instructions are grouped explicitly and trying to add  implicit grouping is problematic.  It would set an unfortunate precedent. 

I still think it best to leave it as is and that simplicity is preferable to adding structures with implicit grouping.  Of course, any implementation of NetRexx can add its own nonstandard extensions, but that is a whole different discussion.

Bill

PS To keep the line counts identical and more closely match the block IF, the NetRexx example above could be coded as below.  I think that shows the impact of the explicit grouping tokens on the "magic number".

IF a = 1 THEN DO
   x = 2
   xx = 22
END; ELSE IF b = 2 THEN DO
   y = 2
   yy = 22
END; ELSE DO
   z = 1
   zz = 11
END    -- admittedly a bit messy

PPS Regarding the dangling ELSE, the problem exists because the ELSE clause is optional.  If a structure with a different keyword is used (e.g. IFE x = 1 THEN y = 2 ELSE y = 3 ) parsing gets a lot easier :).



On 11/21/2011 12:41 PM, George Hovey wrote:

Bill,

Re "The BLOCKIF structure is redundant, and with the goal of keeping the language simple, I think unnecessary. "

Of course IF and BLOCKIF are logically equivalent in the sense that anything expressible with one can be expressed by the other.  And a Turing machine is equivalent to a PC, but nobody wants to program a PC by describing tapes moving to and fro one symbol at a time.

Obviously, that comparison is exaggerated, but I believe that the BLOCKIF is superior to our IF in organizing a complex set of sequential binary decisions: superior, that is, from the perspective of the limitations of human cognition.  Unfortunately, I can't prove this, for several reasons.

• Almost nothing is known of factors affecting the intelligibily of programs.  [ATTENTION LANGUAGE DESIGNERS.  Have you looked at Cognitive Psychology?  Have you ever entertained for one moment the thought that something outside of the computer science curriculum might have a bearing on the usability of programming languages?]  All my conclusions are based on the study of exactly one subject, who may just be a dullard.
  
• I would like to exhibit some comparisons of the two approaches to show that BLOCKIF is clearer, but I would put our IF at an unfair disadvantage because I have never found a way, and I've tried hard, to express a complex series of nested IFs so I can understand it.  I'm often left with a complaining compiler and no clue as to where I went wrong.  [Wouldn't IF Label...End Label be a help here?]

What could be the source of this putative advantage of BLOCKIF?  Here's a guess.  There is a famous paper in cognitive psychology, "The Magic Number Seven Plus or Minus Two," saying, very roughly, that you can keep about 7 things in your head at any given time.  A large body of work says that the key to mentally handling complex relationships is to "chunk" the data:  start with the lowest level and find some way to regard small sets of relations as a single chunk, then move up the chain looking at relationships between the chunks, and naming new chunks.  [This seems closely related to the reason we analyze programs into nested functions, none of which is very long.]  I think I find BLOCKIF so mentally congenial because it gives me a ready-made chunk, so that I can immediately move to thinking about the relationship between these chunks.  Again, just a guess.

On Mon, Nov 21, 2011 at 10:53 AM, Bill Fenlason <[hidden email]> wrote:

Note that in NetRexx, the following are all equivalent:

IF a = 1 THEN x = 2
IF a = 1 ; THEN x = 2
IF a = 1 THEN ; x = 2
IF a = 1 THEN x = 2 ; 
IF a = 1 ; THEN ; x = 2
IF a = 1 ; THEN x = 2 ; 
IF a = 1 THEN ; x = 2 ; 
IF a = 1 ; THEN ; x = 2 ; 

and the 8 variations (for optional semicolons) for each of the following:

IF a = 1 THEN
   x = 2

IF a = 1
   THEN x = 2

IF a = 1
THEN
   x = 2

Similarly, the following are equivalent:

IF a = 1 THEN x = 2 ELSE y = 2

IF a = 1 ;
THEN ;
   x = 2 ;
ELSE ;
   y = 2 ;

as are all of the other arrangements on from 1 to 5 lines.

Each element may occur on any line, and each is optionally followed by a semicolon.  I count a total of 128 arrangements of the 5 elements in an IF-THEN-ELSE construct.

In all of these examples, any of the assignment statements may be replaced by a DO - END, LOOP or SELECT instruction.  In practice, there is often only a single instruction to be executed, and the complex instruction is not necessary.

My point is that the independence of the placement of the parts of an IF construct is fundamental in NetRexx (and Rexx), and it cannot be limited without breakage.

Attempting to introduce some form of the FORTRAN block IF will most likely not work in all of those situations.  I would be more open to the idea of some kind of block IF construct if someone can show me how it would be compatible with all of the current (160) forms of the existing NetRexx IF construct.

As George points out, the only viable approach would be the introduction of a new construct with new keywords, like BLOCKIF, ELSEIF and ENDIF.  But

BLOCKIF a = 1 THEN
   x = 2
ELSE
   y = 2
ENDIF

is equivalent to

IF a = 1 THEN DO
   x = 2
   END
ELSE DO
   y = 2
   END

The BLOCKIF structure is redundant, and with the goal of keeping the language simple, I think unnecessary. 

Adding a new instruction to avoid using DO-END is not justified, in my opinion.

Bill


On 11/21/2011 9:23 AM, George Hovey wrote:
    ...

You are well on the way to inventing the Fortran 77 Block IF statement, except that the efficacy of that construct has been established through more than 30 years of experience.  This is a step in the right direction :) .   Your key insight, in my view, is the realization that this construct need not impact NetRexx's current IF statement, if new keywords are chosen, eg BlockIf, BlockElseIf, BlockElse, BlockEnd.  Of course this should have the same adornments as the current IF (Label, Protect, exception handling, etc).  Why can't we learn from other languages?  Must everything be Invented Here?

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1872 / Virus Database: 2101/4630 - Release Date: 11/21/11

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Hi Bill,

Thanks for the detailed response.  Re "Possibly your feeling about the superiority of the FORTRAN block IF", In the interests of full disclosure I wrote a lot of Fortran 77, so it no doubt tends to look 'right'.  However, it's also true that I never had the feeling that the language was setting traps for me, like C does (and in the case of NetRexx I fear SELECT).

Yes, a decent indentation style would work wonders but I haven't found one.  What I use is your first example.  But I alter it to give END the same indentation as the line containing the DO.  My personal programming standard requires this because I can find the END immediately by scanning directly downwards, whether or not the DO...END is part of an IF, part of some other statement, or standalone; I put a lot of stock in speeding up the process of mental parsing.  Your style (indenting END) reduces clutter (I end up with END and ELSE on consecutive lines at the same level.  I can't have both features and my choice preserves the one most important to me.

Your 'END; ELSE' style is imaginative, but it sticks in my craw to have to tell the compiler where its own clauses end.  I prefer continuation characters.

So, yes I can live with the status quo.   But I'll watch for an instance of an 'IF bank' I can't debug, and perhaps air that issue.

George

P.S.  Any comment on my notion that allowing IF to be labeled could improve the specificity of IF-error diagnostics?

On Mon, Nov 21, 2011 at 2:36 PM, Bill Fenlason <[hidden email]> wrote:

George,

It seems to me that all examples of a block IF, like

BLOCKIF a = 1 THEN
   x = 2

   xx = 22
ELSEIF b = 2 THEN
   y = 2
   yy = 22
ELSE
   z = 1
   zz = 11
ENDIF

can be converted to

IF a = 1 THEN DO
   x = 2

   xx = 22
   END
ELSE IF b = 2 THEN DO
   y = 2
   yy = 22
   END
ELSE DO
   z = 1
   zz = 11
   END

I think it would be useful if you had some examples, but I understand the difficulty.

From a cognitive psychology standpoint, the issue may be the mechanism by which instructions are grouped.  Some languages (e.g. NetRexx) use explicit tokens, like DO ... END or { ... }.  Others use implicit clues, like indentation or an ending assumed by the existence of a following keyword.  It's reasonable to assume that explicit grouping tokens impact the "magic number" more than does implicit grouping.

Possibly your feeling about the superiority of the FORTRAN block IF is due to the fact that most of the grouping mechanism tokens are omitted, thus reducing the "magic number"? 

I don't think there is any easy answer with regard to NetRexx.  Instructions are grouped explicitly and trying to add  implicit grouping is problematic.  It would set an unfortunate precedent. 

I still think it best to leave it as is and that simplicity is preferable to adding structures with implicit grouping.  Of course, any implementation of NetRexx can add its own nonstandard extensions, but that is a whole different discussion.

Bill

PS To keep the line counts identical and more closely match the block IF, the NetRexx example above could be coded as below.  I think that shows the impact of the explicit grouping tokens on the "magic number".

IF a = 1 THEN DO
   x = 2

   xx = 22
END; ELSE IF b = 2 THEN DO
   y = 2
   yy = 22
END; ELSE DO
   z = 1
   zz = 11
END    -- admittedly a bit messy

PPS Regarding the dangling ELSE, the problem exists because the ELSE clause is optional.  If a structure with a different keyword is used (e.g. IFE x = 1 THEN y = 2 ELSE y = 3 ) parsing gets a lot easier :).

On 11/21/2011 12:41 PM, George Hovey wrote:

Bill,

Re "The BLOCKIF structure is redundant, and with the goal of keeping the language simple, I think unnecessary. "

Of course IF and BLOCKIF are logically equivalent in the sense that anything expressible with one can be expressed by the other.  And a Turing machine is equivalent to a PC, but nobody wants to program a PC by describing tapes moving to and fro one symbol at a time.

Obviously, that comparison is exaggerated, but I believe that the BLOCKIF is superior to our IF in organizing a complex set of sequential binary decisions: superior, that is, from the perspective of the limitations of human cognition.  Unfortunately, I can't prove this, for several reasons.

• Almost nothing is known of factors affecting the intelligibily of programs.  [ATTENTION LANGUAGE DESIGNERS.  Have you looked at Cognitive Psychology?  Have you ever entertained for one moment the thought that something outside of the computer science curriculum might have a bearing on the usability of programming languages?]  All my conclusions are based on the study of exactly one subject, who may just be a dullard.
  
• I would like to exhibit some comparisons of the two approaches to show that BLOCKIF is clearer, but I would put our IF at an unfair disadvantage because I have never found a way, and I've tried hard, to express a complex series of nested IFs so I can understand it.  I'm often left with a complaining compiler and no clue as to where I went wrong.  [Wouldn't IF Label...End Label be a help here?]

What could be the source of this putative advantage of BLOCKIF?  Here's a guess.  There is a famous paper in cognitive psychology, "The Magic Number Seven Plus or Minus Two," saying, very roughly, that you can keep about 7 things in your head at any given time.  A large body of work says that the key to mentally handling complex relationships is to "chunk" the data:  start with the lowest level and find some way to regard small sets of relations as a single chunk, then move up the chain looking at relationships between the chunks, and naming new chunks.  [This seems closely related to the reason we analyze programs into nested functions, none of which is very long.]  I think I find BLOCKIF so mentally congenial because it gives me a ready-made chunk, so that I can immediately move to thinking about the relationship between these chunks.  Again, just a guess.

On Mon, Nov 21, 2011 at 10:53 AM, Bill Fenlason <[hidden email]> wrote:

Note that in NetRexx, the following are all equivalent:

IF a = 1 THEN x = 2
IF a = 1 ; THEN x = 2
IF a = 1 THEN ; x = 2
IF a = 1 THEN x = 2 ; 
IF a = 1 ; THEN ; x = 2
IF a = 1 ; THEN x = 2 ; 
IF a = 1 THEN ; x = 2 ; 
IF a = 1 ; THEN ; x = 2 ; 

and the 8 variations (for optional semicolons) for each of the following:

IF a = 1 THEN
   x = 2

IF a = 1
   THEN x = 2

IF a = 1
THEN
   x = 2

Similarly, the following are equivalent:

IF a = 1 THEN x = 2 ELSE y = 2

IF a = 1 ;
THEN ;
   x = 2 ;
ELSE ;
   y = 2 ;

as are all of the other arrangements on from 1 to 5 lines.

Each element may occur on any line, and each is optionally followed by a semicolon.  I count a total of 128 arrangements of the 5 elements in an IF-THEN-ELSE construct.

In all of these examples, any of the assignment statements may be replaced by a DO - END, LOOP or SELECT instruction.  In practice, there is often only a single instruction to be executed, and the complex instruction is not necessary.

My point is that the independence of the placement of the parts of an IF construct is fundamental in NetRexx (and Rexx), and it cannot be limited without breakage.

Attempting to introduce some form of the FORTRAN block IF will most likely not work in all of those situations.  I would be more open to the idea of some kind of block IF construct if someone can show me how it would be compatible with all of the current (160) forms of the existing NetRexx IF construct.

As George points out, the only viable approach would be the introduction of a new construct with new keywords, like BLOCKIF, ELSEIF and ENDIF.  But

BLOCKIF a = 1 THEN
   x = 2
ELSE
   y = 2
ENDIF

is equivalent to

IF a = 1 THEN DO
   x = 2
   END
ELSE DO
   y = 2
   END

The BLOCKIF structure is redundant, and with the goal of keeping the language simple, I think unnecessary. 

Adding a new instruction to avoid using DO-END is not justified, in my opinion.

Bill


On 11/21/2011 9:23 AM, George Hovey wrote:
    ...

You are well on the way to inventing the Fortran 77 Block IF statement, except that the efficacy of that construct has been established through more than 30 years of experience.  This is a step in the right direction :) .   Your key insight, in my view, is the realization that this construct need not impact NetRexx's current IF statement, if new keywords are chosen, eg BlockIf, BlockElseIf, BlockElse, BlockEnd.  Of course this should have the same adornments as the current IF (Label, Protect, exception handling, etc).  Why can't we learn from other languages?  Must everything be Invented Here?

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1872 / Virus Database: 2101/4630 - Release Date: 11/21/11

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

On 11/21/2011 4:10 PM, George Hovey wrote:
     ...
> P.S.  Any comment on my notion that allowing IF to be labeled could
> improve the specificity of IF-error diagnostics?

Since the IF instruction syntax begins  "IF expression [;]  ..." and the
DO, LOOP and SELECT instructions begin differently (with a keyword,
e.g.  "DO  LABEL  name ...") there is a conflict between the LABEL
keyword and the expression in the IF expression.

Thus "IF  LABEL name  boolVariable"  would be ambiguous since "LABEL
name boolVariable" is also an expression using blank concatenation.

This is a perfect example of the kind of situation Mike was guarding
against with his approach to keyword safety.  If implemented, NetRexx
would first look for a variable named "LABEL", and if not found, assume
that LABEL is a keyword.  As I've said earlier I'm not fond of that
approach, but C'est la vie.  I don't think adding a labelled IF
statement to NetRexx is a good idea from a syntax viewpoint.

Bill


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Dave Woodman]

Well I, for one, have never worked for IM, and am not yet near retirement!

 

How, then, did I get here?

 

In the late 80’s, my first job was in telecoms R&D in a (then) CMS shop, and I started to use Rexx in response to someone else trying to get me to use EXEC2.  Rexx was in no way my first language, nor my last, but stayed a warm memory.

 

The shop moved away from CMS, and thus I moved away from Rexx, with Rexx remaining a memory until I needed to do some OLE scripting, and thus I ended up with ooRrexx, noting on the way that

 

a)      NetRexx existed

b)      NetRexx was going to be open source

c)       NetRexx was compiled (a holy grail to other Rexx dialects unless rich)

 

With these things in mind, I proceeded to use ooRexx (for the OLE support) but kept an eye on the open-source status of NetRexx

 

So, why did I come back to the Rexx family after so many years, especially when there are so many other scripting languages available? The answers are applicable to both ooRexx and NetRexx with the exception of observation c), above.

 

a)      Rexx is a ‘learn-once’ language – I have learned many languages, and find, after a spell away you need to re-learn much of what you learned before. (Perl is like this). The fact that Rexx is small is the key here.

b)      Rexx remains readable, even if you can’t be bothered to comment – at least as long as you use sensible variable names

c)       Rexx has very little fuss-and-bother – this is especially appreciated when using OO programming – not much overheard to achieve what is needed.

d)      Adding to the above point – the OO capabilities are cleanly implemented.

 

Specifically for NetRexx

 

a)      The ability to code what is really java in a “nice” language like Rexx

b)      The fact that you can make use of all of the other work that is available for Java means that many problems are already solved for you

c)       It is compiled – OK, I know that it is really an intermediate code (a-la P-CODE) but Java code rivals native these days.

d)      It remains “learn-once” – the step from classic  or ooRexx to NetRexx is small.

 

So, from my viewpoint, please avoid adding too much to the language – its small size and readable nature are its strengths. Of course it has some weaknesses, as do all languages, but it is unrivalled (at least for me) in terms of productivity and ease of expression.

 

                Cheers,

 

                                Dave.   

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: 21 November 2011 14:24
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Changes to Select

 

Hi Kermit,
Just a couple of comments.  Re

"I suspect that most if not all NetRexx newbies actually come from the Rexx groups"

This is what we must work to change.  The constant bowing to Rexx suggests that we are preaching to the choir.  If NetRexx is just a plaything for IBM retirees its future is bleak.  We should be working to assure that many newbies come from other languages, and especially Java, because of the special contribution they can make.  Rexx may be only a word to those people.  Our primary pitch should be "NetRexx = Humanistic Java."

Re

CHECKCONDITION

  ONCONDITION expression

    instructionlist

  ONCONDITION expression

    instructionlist

  ONOTHERCONDITIONS

    instructionlist

END -- CHECK

You are well on the way to inventing the Fortran 77 Block IF statement, except that the efficacy of that construct has been established through more than 30 years of experience.  This is a step in the right direction :) .   Your key insight, in my view, is the realization that this construct need not impact NetRexx's current IF statement, if new keywords are chosen, eg BlockIf, BlockElseIf, BlockElse, BlockEnd.  Of course this should have the same adornments as the current IF (Label, Protect, exception handling, etc).  Why can't we learn from other languages?  Must everything be Invented Here?

 

On Sun, Nov 20, 2011 at 7:48 PM, Kermit Kiser <[hidden email]> wrote:

Mike -

Thanks for your comments. You have convinced me not to open an issue for this item. That is not because I agree with your arguments, but in order to "choose my battles" because there are critical problems to fix (like the method resolution bugs), whereas the SELECT inconsistency is at worst a minor annoyance and I seldom use the select instruction. (I am still trying to figure out whether I seldom use it because the inconsistency makes it hard to remember how or if it is hard to remember how it works because I seldom use it! ;-) The only argument for the status quo that makes sense to me is that it matches classic and object Rexx behavior and that is important because I suspect that most if not all NetRexx newbies actually come from the Rexx groups.

And I think I am beginning to see why there is so much resistance to change here and where our difference in philosophy arises. From your comments it appears that you and possibly others view SELECT as an extended version of the IF statement which makes cascading "IF...THEN...ELSE IF...THEN...ELSE IF...THEN..." constructs easier to express, whereas I (and possibly others) view it as a completely separate instruction from IF which has no relationship except that it is a conditional construct as is LOOP.  From my view, the THEN keyword in the WHEN construct adds nothing while from your view it connects it conceptually to the IF...THEN statement. Unfortunately, if I were to adopt your view it would only confuse me more because the IF statement has both THEN and ELSE keywords while the WHEN construct only has a THEN keyword which is still a puzzling inconsistency to me.

If I were to design a SELECT instruction based on the extended IF view, it would probably look something like this:

SELECT

  IF ..... THEN instruction

    ELSE instruction

  IF ..... THEN instruction

    ELSE instruction

  OTHERWISE instruction

END

For now, lets agree to disagree!

-- Kermit

PS: Of course, there is another option too! NetRexx could add another completely different conditional construct somewhat like this:

CHECKCONDITION

  ONCONDITION expression

    instructionlist

  ONCONDITION expression

    instructionlist

  ONOTHERCONDITIONS

    instructionlist

END -- CHECK

On 11/20/2011 4:03 AM, Mike Cowlishaw wrote:

Kermit, thanks for the detailed thoughts.  Also thanks to Dave Woodman for the pointer for 'Outlook bar breaking'.

 

---

Please pardon my preamble here - it is relevant. As far as changes to NetRexx go, I am probably a moderate, somewhere in between those who want to add any feature they have ever seen in any computer language and those who don't want any changes, even to fix obvious problems. I follow this guideline: Don't make any changes to NetRexx unless there is a very clear and significant improvement, whether fixing a "broken behavior" type problem or adding a feature to improve Java interoperability or whatever. That is why I have not yet decided if this item is worth opening a change issue on Kenai or not. But here is an interesting quote that I found in TNRL: "Programming languages invariably need to evolve over time as the needs and expectations of their users change". 

Absolutely.  One has to be a bit careful over the definition of 'user', however -- for the Rexx languages I've always tried to design for the fallible 'average' user rather than the skilled rarely-makes-a-mistake developer.  (In contrast to systems and assembler languages I've designed, where programmer and program efficiency are paramount).

This particular issue is not a big deal to me especially since one easy fix, as others have pointed out, is to always use explicit DO...END blocks when grouping instructions thus ignoring the language inconsistencies. In fact, another fix might be to change NetRexx to disallow the implied DO groups and always force explicit grouping (of course that could break existing code!) for more consistency. That said, the SELECT instruction is the one NetRexx instruction that violates the basic NetRexx principle of "least astonishment" for me and always forces me to look it up before I use it - Why do I need an explicit DO...END group to do anything significant WHEN I have a matching condition but don't need the explicit DO...END to handle the non-matching case (OTHERWISE)?  

As it happens, I argued (for Rexx) that OTHERWISE should require DO...END for exactly the reason you suggest, but was outvoted by the users :-).   However, with hindsight -- and perhaps more so for NetRexx -- it seems OK, because really one can think of OTHERWISE as just a special case of CATCH ... a shorthand for 'CATCH NoOtherwiseException;' (which should have had a better name, perhaps -- "CaseNotHandledException" or something like that).

 

Now, I agree that one could argue that the WHENs could be considered some special type of CATCH-like thing, too, and could be 'precompiled' in many cases (especially when CASE is used and the cases are constants).  But in general they are a cascade of IF a THEN b ELSE IF c THEN d ELSE IF e THEN ... [etc.] .. which is really a different sort of animal -- a sequential flow of executed expressions and tests.   I think making WHEN clauses look like CASE statements in C or Java is going to be confusing to anyone coming from those languages, because in C or Java they would drop through to the next CASE (WHEN in NetRexx) -- but I think you are proposing that on reaching the next WHEN control would transfer to the end of the SELECT.

 

I'm also uncomfortable with the idea that THEN becomes 'optional'.  Sometimes it could be there, and sometimes not.  That will be confusing to readers, and once the confusion is there then it will affect the writing of IF constructs, too, and cause confusion there.   In other words .. a change that seems to be just a tweak on SELECT has a wider impact that needs to be considered part of the change: making THEN optional on WHEN means one really ought to make it optional on IF, too -- but does that mean that when THEN is omitted after IF the IF can be followed by a number of statements that are considered part of the "then" instructionlist, ended by the next IF?  If not, then we've introduced another inconsistency. 

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

[Not going to be able to catch up on this thread for a few days .. still haven't cleared the backlog from USA trip and some additional urgent things have turned up yesterday :-(]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Dave,
Well said!  This belongs on our site.
George

On Mon, Nov 21, 2011 at 5:16 PM, Dave Woodman <[hidden email]> wrote:

Well I, for one, have never worked for IM, and am not yet near retirement!

 

How, then, did I get here?

 

In the late 80’s, my first job was in telecoms R&D in a (then) CMS shop, and I started to use Rexx in response to someone else trying to get me to use EXEC2.  Rexx was in no way my first language, nor my last, but stayed a warm memory.

 

The shop moved away from CMS, and thus I moved away from Rexx, with Rexx remaining a memory until I needed to do some OLE scripting, and thus I ended up with ooRrexx, noting on the way that

 

a)      NetRexx existed

b)      NetRexx was going to be open source

c)       NetRexx was compiled (a holy grail to other Rexx dialects unless rich)

 

With these things in mind, I proceeded to use ooRexx (for the OLE support) but kept an eye on the open-source status of NetRexx

 

So, why did I come back to the Rexx family after so many years, especially when there are so many other scripting languages available? The answers are applicable to both ooRexx and NetRexx with the exception of observation c), above.

 

a)      Rexx is a ‘learn-once’ language – I have learned many languages, and find, after a spell away you need to re-learn much of what you learned before. (Perl is like this). The fact that Rexx is small is the key here.

b)      Rexx remains readable, even if you can’t be bothered to comment – at least as long as you use sensible variable names

c)       Rexx has very little fuss-and-bother – this is especially appreciated when using OO programming – not much overheard to achieve what is needed.

d)      Adding to the above point – the OO capabilities are cleanly implemented.

 

Specifically for NetRexx

 

a)      The ability to code what is really java in a “nice” language like Rexx

b)      The fact that you can make use of all of the other work that is available for Java means that many problems are already solved for you

c)       It is compiled – OK, I know that it is really an intermediate code (a-la P-CODE) but Java code rivals native these days.

d)      It remains “learn-once” – the step from classic  or ooRexx to NetRexx is small.

 

So, from my viewpoint, please avoid adding too much to the language – its small size and readable nature are its strengths. Of course it has some weaknesses, as do all languages, but it is unrivalled (at least for me) in terms of productivity and ease of expression.

 

                Cheers,

 

                                Dave.   

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: 21 November 2011 14:24
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Changes to Select

 

Hi Kermit,
Just a couple of comments.  Re

"I suspect that most if not all NetRexx newbies actually come from the Rexx groups"

This is what we must work to change.  The constant bowing to Rexx suggests that we are preaching to the choir.  If NetRexx is just a plaything for IBM retirees its future is bleak.  We should be working to assure that many newbies come from other languages, and especially Java, because of the special contribution they can make.  Rexx may be only a word to those people.  Our primary pitch should be "NetRexx = Humanistic Java."

Re

CHECKCONDITION

  ONCONDITION expression

    instructionlist

  ONCONDITION expression

    instructionlist

  ONOTHERCONDITIONS

    instructionlist

END -- CHECK

You are well on the way to inventing the Fortran 77 Block IF statement, except that the efficacy of that construct has been established through more than 30 years of experience.  This is a step in the right direction :) .   Your key insight, in my view, is the realization that this construct need not impact NetRexx's current IF statement, if new keywords are chosen, eg BlockIf, BlockElseIf, BlockElse, BlockEnd.  Of course this should have the same adornments as the current IF (Label, Protect, exception handling, etc).  Why can't we learn from other languages?  Must everything be Invented Here?

 

On Sun, Nov 20, 2011 at 7:48 PM, Kermit Kiser <[hidden email]> wrote:

Mike -

Thanks for your comments. You have convinced me not to open an issue for this item. That is not because I agree with your arguments, but in order to "choose my battles" because there are critical problems to fix (like the method resolution bugs), whereas the SELECT inconsistency is at worst a minor annoyance and I seldom use the select instruction. (I am still trying to figure out whether I seldom use it because the inconsistency makes it hard to remember how or if it is hard to remember how it works because I seldom use it! ;-) The only argument for the status quo that makes sense to me is that it matches classic and object Rexx behavior and that is important because I suspect that most if not all NetRexx newbies actually come from the Rexx groups.

And I think I am beginning to see why there is so much resistance to change here and where our difference in philosophy arises. From your comments it appears that you and possibly others view SELECT as an extended version of the IF statement which makes cascading "IF...THEN...ELSE IF...THEN...ELSE IF...THEN..." constructs easier to express, whereas I (and possibly others) view it as a completely separate instruction from IF which has no relationship except that it is a conditional construct as is LOOP.  >From my view, the THEN keyword in the WHEN construct adds nothing while from your view it connects it conceptually to the IF...THEN statement. Unfortunately, if I were to adopt your view it would only confuse me more because the IF statement has both THEN and ELSE keywords while the WHEN construct only has a THEN keyword which is still a puzzling inconsistency to me.

If I were to design a SELECT instruction based on the extended IF view, it would probably look something like this:

SELECT

  IF ..... THEN instruction

    ELSE instruction

  IF ..... THEN instruction

    ELSE instruction

  OTHERWISE instruction

END

For now, lets agree to disagree!

-- Kermit

PS: Of course, there is another option too! NetRexx could add another completely different conditional construct somewhat like this:

CHECKCONDITION

  ONCONDITION expression

    instructionlist

  ONCONDITION expression

    instructionlist

  ONOTHERCONDITIONS

    instructionlist

END -- CHECK

On 11/20/2011 4:03 AM, Mike Cowlishaw wrote:

Kermit, thanks for the detailed thoughts.  Also thanks to Dave Woodman for the pointer for 'Outlook bar breaking'.

 

---

Please pardon my preamble here - it is relevant. As far as changes to NetRexx go, I am probably a moderate, somewhere in between those who want to add any feature they have ever seen in any computer language and those who don't want any changes, even to fix obvious problems. I follow this guideline: Don't make any changes to NetRexx unless there is a very clear and significant improvement, whether fixing a "broken behavior" type problem or adding a feature to improve Java interoperability or whatever. That is why I have not yet decided if this item is worth opening a change issue on Kenai or not. But here is an interesting quote that I found in TNRL: "Programming languages invariably need to evolve over time as the needs and expectations of their users change". 

Absolutely.  One has to be a bit careful over the definition of 'user', however -- for the Rexx languages I've always tried to design for the fallible 'average' user rather than the skilled rarely-makes-a-mistake developer.  (In contrast to systems and assembler languages I've designed, where programmer and program efficiency are paramount).

This particular issue is not a big deal to me especially since one easy fix, as others have pointed out, is to always use explicit DO...END blocks when grouping instructions thus ignoring the language inconsistencies. In fact, another fix might be to change NetRexx to disallow the implied DO groups and always force explicit grouping (of course that could break existing code!) for more consistency. That said, the SELECT instruction is the one NetRexx instruction that violates the basic NetRexx principle of "least astonishment" for me and always forces me to look it up before I use it - Why do I need an explicit DO...END group to do anything significant WHEN I have a matching condition but don't need the explicit DO...END to handle the non-matching case (OTHERWISE)?  

As it happens, I argued (for Rexx) that OTHERWISE should require DO...END for exactly the reason you suggest, but was outvoted by the users :-).   However, with hindsight -- and perhaps more so for NetRexx -- it seems OK, because really one can think of OTHERWISE as just a special case of CATCH ... a shorthand for 'CATCH NoOtherwiseException;' (which should have had a better name, perhaps -- "CaseNotHandledException" or something like that).

 

Now, I agree that one could argue that the WHENs could be considered some special type of CATCH-like thing, too, and could be 'precompiled' in many cases (especially when CASE is used and the cases are constants).  But in general they are a cascade of IF a THEN b ELSE IF c THEN d ELSE IF e THEN ... [etc.] .. which is really a different sort of animal -- a sequential flow of executed expressions and tests.   I think making WHEN clauses look like CASE statements in C or Java is going to be confusing to anyone coming from those languages, because in C or Java they would drop through to the next CASE (WHEN in NetRexx) -- but I think you are proposing that on reaching the next WHEN control would transfer to the end of the SELECT.

 

I'm also uncomfortable with the idea that THEN becomes 'optional'.  Sometimes it could be there, and sometimes not.  That will be confusing to readers, and once the confusion is there then it will affect the writing of IF constructs, too, and cause confusion there.   In other words .. a change that seems to be just a tweak on SELECT has a wider impact that needs to be considered part of the change: making THEN optional on WHEN means one really ought to make it optional on IF, too -- but does that mean that when THEN is omitted after IF the IF can be followed by a number of statements that are considered part of the "then" instructionlist, ended by the next IF?  If not, then we've introduced another inconsistency. 

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

Kermit, thanks.  In tryth, I completely sympathise with your view -- I, too, had radical ideas for conditional constructs (both IF-like and SELECT-like) whcih I think were cleaner than the existing forms (or the IF -- ENDIF varieties) .. but could not argue against the status-quo (then PL/I and PL/M) that was so entrenched.

 

James Gosling had the same problem with Oak (that became Java).  He really wanted to change from the { } braces but that was too radical for the entrenched C diehards.

 

plus ça change, plus c'est la même chose  :-)

 

At least this little bit of history has ben recorded so perhaps it won't be lost again.

 

Mike

 

Thanks for your comments. You have convinced me not to open an issue for this item. That is not because I agree with your arguments, but in order to "choose my battles" because there are critical problems to fix (like the method resolution bugs), whereas the SELECT inconsistency is at worst a minor annoyance and I seldom use the select instruction. (I am still trying to figure out whether I seldom use it because the inconsistency makes it hard to remember how or if it is hard to remember how it works because I seldom use it! ;-) The only argument for the status quo that makes sense to me is that it matches classic and object Rexx behavior and that is important because I suspect that most if not all NetRexx newbies actually come from the Rexx groups.

And I think I am beginning to see why there is so much resistance to change here and where our difference in philosophy arises. From your comments it appears that you and possibly others view SELECT as an extended version of the IF statement which makes cascading "IF...THEN...ELSE IF...THEN...ELSE IF...THEN..." constructs easier to express, whereas I (and possibly others) view it as a completely separate instruction from IF which has no relationship except that it is a conditional construct as is LOOP.  From my view, the THEN keyword in the WHEN construct adds nothing while from your view it connects it conceptually to the IF...THEN statement. Unfortunately, if I were to adopt your view it would only confuse me more because the IF statement has both THEN and ELSE keywords while the WHEN construct only has a THEN keyword which is still a puzzling inconsistency to me.

If I were to design a SELECT instruction based on the extended IF view, it would probably look something like this:

SELECT

  IF ..... THEN instruction

    ELSE instruction

  IF ..... THEN instruction

    ELSE instruction

  OTHERWISE instruction

END

For now, lets agree to disagree!

-- Kermit

PS: Of course, there is another option too! NetRexx could add another completely different conditional construct somewhat like this:

CHECKCONDITION

  ONCONDITION expression

    instructionlist

  ONCONDITION expression

    instructionlist

  ONOTHERCONDITIONS

    instructionlist

END -- CHECK

On 11/20/2011 4:03 AM, Mike Cowlishaw wrote:

Kermit, thanks for the detailed thoughts.  Also thanks to Dave Woodman for the pointer for 'Outlook bar breaking'.

---

Please pardon my preamble here - it is relevant. As far as changes to NetRexx go, I am probably a moderate, somewhere in between those who want to add any feature they have ever seen in any computer language and those who don't want any changes, even to fix obvious problems. I follow this guideline: Don't make any changes to NetRexx unless there is a very clear and significant improvement, whether fixing a "broken behavior" type problem or adding a feature to improve Java interoperability or whatever. That is why I have not yet decided if this item is worth opening a change issue on Kenai or not. But here is an interesting quote that I found in TNRL: "Programming languages invariably need to evolve over time as the needs and expectations of their users change". 

Absolutely.  One has to be a bit careful over the definition of 'user', however -- for the Rexx languages I've always tried to design for the fallible 'average' user rather than the skilled rarely-makes-a-mistake developer.  (In contrast to systems and assembler languages I've designed, where programmer and program efficiency are paramount).

This particular issue is not a big deal to me especially since one easy fix, as others have pointed out, is to always use explicit DO...END blocks when grouping instructions thus ignoring the language inconsistencies. In fact, another fix might be to change NetRexx to disallow the implied DO groups and always force explicit grouping (of course that could break existing code!) for more consistency. That said, the SELECT instruction is the one NetRexx instruction that violates the basic NetRexx principle of "least astonishment" for me and always forces me to look it up before I use it - Why do I need an explicit DO...END group to do anything significant WHEN I have a matching condition but don't need the explicit DO...END to handle the non-matching case (OTHERWISE)?  

As it happens, I argued (for Rexx) that OTHERWISE should require DO...END for exactly the reason you suggest, but was outvoted by the users :-).   However, with hindsight -- and perhaps more so for NetRexx -- it seems OK, because really one can think of OTHERWISE as just a special case of CATCH ... a shorthand for 'CATCH NoOtherwiseException;' (which should have had a better name, perhaps -- "CaseNotHandledException" or something like that).

 

Now, I agree that one could argue that the WHENs could be considered some special type of CATCH-like thing, too, and could be 'precompiled' in many cases (especially when CASE is used and the cases are constants).  But in general they are a cascade of IF a THEN b ELSE IF c THEN d ELSE IF e THEN ... [etc.] .. which is really a different sort of animal -- a sequential flow of executed expressions and tests.   I think making WHEN clauses look like CASE statements in C or Java is going to be confusing to anyone coming from those languages, because in C or Java they would drop through to the next CASE (WHEN in NetRexx) -- but I think you are proposing that on reaching the next WHEN control would transfer to the end of the SELECT.

 

I'm also uncomfortable with the idea that THEN becomes 'optional'.  Sometimes it could be there, and sometimes not.  That will be confusing to readers, and once the confusion is there then it will affect the writing of IF constructs, too, and cause confusion there.   In other words .. a change that seems to be just a tweak on SELECT has a wider impact that needs to be considered part of the change: making THEN optional on WHEN means one really ought to make it optional on IF, too -- but does that mean that when THEN is omitted after IF the IF can be followed by a number of statements that are considered part of the "then" instructionlist, ended by the next IF?  If not, then we've introduced another inconsistency. 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/