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

[ThSITC]

Hello George, and all, again:

The *CLUMSY*, as I see it, does come from the SYNTAX:

IF condition [;] THEN [;] instruction

*or*

SELECT ...
    WHEN condition [;] THEN [;] instruction

The first (optional) semicolon *or Carriage Return* is *NO Problem at all*!

What has to catered for, is the currently OPTIONAL Semicolon AFTER the THEN!

Thus,

IF condition THEN instruction      -- is a SIMPLE IF

IF condition THEN
    instructions     -- as Rony spelled it
END IF

Shall be a Structured IF statement..

Then, of course, even the keyword THEN might be optional...

e.g.:

IF condition
    instructions
END IF

Same with ELSE, WHEN, etc, of course...

Comprendi?
Thomas.

 
Am 21.11.2011 15:23, schrieb George Hovey:

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/

[ThSITC]

*and*, that is the one and only one *fault*:

Having different syntactic representations *without* a different *semantic meaning*!

Thomas.

Am 21.11.2011 16:53, schrieb Bill Fenlason:

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/

[ThSITC]

Hello Walter,
    whilst IF is a statement(!) ELSE after an IF is NOT recognised
That's what I'm talinkg about (relating HUMAN oriented Languages!!)

Thomas.
================================================================

Am 21.11.2011 17:10, schrieb Walter 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/
>
>

--
Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge
Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team
(www.netrexx.org)

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

[ThSITC]

Hi Bill,
    it all DOES depend when and where we do consider an IF to be a
STRUCTURED IF,
or a SIMPLE IF:

Simple IF:

     IF condtion THEN instruction

Structured IF:

    IF condition [THEN]
        instructions
    END IF

See at the Fortran 77 reference manuals for this important difference(s).

Thomas.

==========================================================================

Am 21.11.2011 22:50, schrieb Bill Fenlason:

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

--
Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge
Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team
(www.netrexx.org)

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

[ThSITC]

FORTAN 77 did solve it to distinguinsh:

if (a) line1,line2,line3

*from*

if (a) THEN statement


**from **  the so called STRUCTURED IF
Thomas.

Am 21.11.2011 19:44, schrieb Robert 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/

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