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

[ThSITC]

Hello there, I'm knowing I'm going on your nerves (as Chip said: trying
to change *the Language*)

My personal opinion is, that:

(a) a SEMICOLON shall be equivalent to a Carriage RETURN (CR)    [as it
is now]
(b) the different versions of the IF/ELSE IF/OTHERWISE variations shall
have a DIFFERENT
semantic meaning:

I will try to explain it with some samples:

1.) the SIMPLE IF-Statement

      IF condition THEN instruction [ELSE instruction]

as current implementation, BUT: ELSE shall be recognized as a KEYWORD
after any IF)
even when the semicolon before the ELSE is missing!

2.) The SIMPLE IF Statement (Format 2)

    IF condition
    THEN instruction [ELSE instruction]

shall be equivalen to the above case 1.)

3.) The STRUCTURED IF Statement shall be DEFINED as in FORTRAN 77:

    IF Condition  [THEN]  (CR)
        instructions
    ELSE instruction

4.) introduction of the END IF (only needed in this last case)

    IF Condition (CR)
       instructions
    ELSE (CR)
      instructions
    END IF (CR)

5.) By simply allowing an END IF statement, we can make all of that more
easier...

:In case 4, above, END IF can be abbreviated to END (as now)

The ';' and (CR) delimiter might be used interchangebly then, and a LOT of
DO .. END's might be saved.


Please read (ggogle) the FORTRAN 77 and 92 specs's for the structured
IF statement, when you like .....

===================================================================
Greetings from dark Vienna,
Thomas.

PS: The whole INTENT is, to give the SEMICOLON in the SYNTAX Definition
a SEMANTIC meaning!!

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

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

[billfen]

Thomas,

The issue of the difference between the end of line and a semicolon is a red herring in this discussion.

There are two approaches in defining the syntax for an IF construct.  The first uses an explicit ending (such as ENDIF or END something) and the second does not.  Either is sufficient.

NetRexx uses only the second form, and determines the end of the IF construct by finding the end of the ELSE instruction (or the THEN instruction if the ELSE clause is missing).  The THEN and ELSE instructions may be complex instructions, such as DO, LOOP, etc.   

Any attempt to add an optional explicit end to the existing NetRexx IF construct will add significant user error possibilities and reduce the clarity of the program structure.  Adding a mandatory end is out of the question because of breakage.

For example, the following is valid NetRexx and always results in two initial output lines
    ...
    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
         say  "Start (true)"
    ELSE
         say  "Start (false)"
    say  "Next"    -- Always executed   
    --  Many more statements
/* end of file */ 

If an optional explicit ending for the IF statement is added to NetRexx, consider the following:
    ...
    IF  a =  b  c   -- Note no semicolons or parens, and blank concatenate
    THEN
         say  "Start (true)"
    ELSE
          say  "Start (false)"
    say  "Next"    -- Unknown if this will be executed (requires look ahead)
    --  Many more statements
   END IF    -- If present, changes the program structure and execution
/* end of file */ 

Obviously that may be unexpected and confusing, and is contrary to the fundamental simplicity of Rexx.

Mike wrote the following in the language reference manual (emphasis mine):

"NetRexx is designed as a small language. It is not the sum of all the features of Rexx and of Java; rather, unnecessary features have been omitted. The intention has been to keep the language as small as possible, so that users can rapidly grasp most of the language. This means that:
    • the language appears less formidable to the new user
    • documentation is smaller and simpler
    • the experienced user can be aware of all the abilities of the language, and so has the whole tool at his or her disposal
    • there are few exceptions, special cases, or rarely used embellishments
    • the language is easier to implement.
Many languages have accreted “neat” features which make certain algorithms easier to express; analysis shows that many of these are rarely used. As a rough rule-of-thumb, features that simply provided alternative ways of writing code were added to Rexx and NetRexx only if they were likely to be used more often than once in five thousand clauses."

It would seem that adding unnecessary features to NetRexx should be strongly avoided.  In my opinion, that includes most of the currently suggested language extensions.  Java is a better solution if bells and whistles are desired.

Adding an explicit end to the NetRexx IF is clearly not needed, and it is unlikely that it will ever be added to standard NetRexx.  The concept is described in the language reference manual under "Limited span syntactic units".  The lack of an explicit end for an IF construct is most likely intentional.   While a dislike of DO ... END is understandable, an explicit end for the IF structure is not a viable replacement and would make NetRexx worse, not better.

Thomas, if you prefer a language that uses an explicit ending for an IF construct, perhaps you should stick to FORTRAN or any of the other languages that use that approach.  Note that Java does not.

As I suggested before, please implement and test your IF construct ideas in your own "NetRexx-like" language first, instead of continuing to suggest them here.  You are not "getting on my nerves", but it is a bit tiresome.  The horse was dead and buried long ago. 

Bill


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

[Kermit Kiser]

Thomas -

This is not a bug in NetRexx nor does your suggestion add any new or
missing functionality to NetRexx. All it does is change NetRexx syntax
to match that of some other language you like better. That is not likely
to happen especially since it looks like it would break most existing
NetRexx programs.

I think you are wasting your time!

-- Kermit


On 11/17/2011 10:49 AM, Thomas Schneider wrote:

> Hello there, I'm knowing I'm going on your nerves (as Chip said:
> trying to change *the Language*)
>
> My personal opinion is, that:
>
> (a) a SEMICOLON shall be equivalent to a Carriage RETURN (CR)    [as
> it is now]
> (b) the different versions of the IF/ELSE IF/OTHERWISE variations
> shall have a DIFFERENT
> semantic meaning:
>
> I will try to explain it with some samples:
>
> 1.) the SIMPLE IF-Statement
>
>      IF condition THEN instruction [ELSE instruction]
>
> as current implementation, BUT: ELSE shall be recognized as a KEYWORD
> after any IF)
> even when the semicolon before the ELSE is missing!
>
> 2.) The SIMPLE IF Statement (Format 2)
>
>    IF condition
>    THEN instruction [ELSE instruction]
>
> shall be equivalen to the above case 1.)
>
> 3.) The STRUCTURED IF Statement shall be DEFINED as in FORTRAN 77:
>
>    IF Condition  [THEN]  (CR)
>        instructions
>    ELSE instruction
>
> 4.) introduction of the END IF (only needed in this last case)
>
>    IF Condition (CR)
>       instructions
>    ELSE (CR)
>      instructions
>    END IF (CR)
>
> 5.) By simply allowing an END IF statement, we can make all of that
> more easier...
>
> :In case 4, above, END IF can be abbreviated to END (as now)
>
> The ';' and (CR) delimiter might be used interchangebly then, and a
> LOT of
> DO .. END's might be saved.
>
>
> Please read (ggogle) the FORTRAN 77 and 92 specs's for the structured
> IF statement, when you like .....
>
> ===================================================================
> Greetings from dark Vienna,
> Thomas.
>
> PS: The whole INTENT is, to give the SEMICOLON in the SYNTAX Definition
> a SEMANTIC meaning!!
>
> ====================================================================
>

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

[Waite, Dick]

 
Regards,

Dick Waite
Mobile: [phone]
--------------------------
Sent using BlackBerry 9700



Software AG - Group Executive Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, Dr. Wolfram Jost, Kamyar Niroumand, Darren Roos, Jonathan Smith, Ivo Totev

Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany - Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt http://www.softwareag.com/
----- Original Message -----

From: Thomas Schneider [mailto:[hidden email]]
Sent: Thursday, November 17, 2011 07:49 PM
To: IBM Netrexx <[hidden email]>
Subject: [Ibm-netrexx] A (my) proposal for an IMPROVED IF/THEN/ELSE/OTHERWISE Syntax (and, SEMANTICS)

Hello there, I'm knowing I'm going on your nerves (as Chip said: trying
to change *the Language*)

My personal opinion is, that:

(a) a SEMICOLON shall be equivalent to a Carriage RETURN (CR)    [as it
is now]
(b) the different versions of the IF/ELSE IF/OTHERWISE variations shall
have a DIFFERENT
semantic meaning:

I will try to explain it with some samples:

1.) the SIMPLE IF-Statement

      IF condition THEN instruction [ELSE instruction]

as current implementation, BUT: ELSE shall be recognized as a KEYWORD
after any IF)
even when the semicolon before the ELSE is missing!

2.) The SIMPLE IF Statement (Format 2)

    IF condition
    THEN instruction [ELSE instruction]

shall be equivalen to the above case 1.)

3.) The STRUCTURED IF Statement shall be DEFINED as in FORTRAN 77:

    IF Condition  [THEN]  (CR)
        instructions
    ELSE instruction

4.) introduction of the END IF (only needed in this last case)

    IF Condition (CR)
       instructions
    ELSE (CR)
      instructions
    END IF (CR)

5.) By simply allowing an END IF statement, we can make all of that more
easier...

:In case 4, above, END IF can be abbreviated to END (as now)

The ';' and (CR) delimiter might be used interchangebly then, and a LOT of
DO .. END's might be saved.


Please read (ggogle) the FORTRAN 77 and 92 specs's for the structured
IF statement, when you like .....

===================================================================
Greetings from dark Vienna,
Thomas.

PS: The whole INTENT is, to give the SEMICOLON in the SYNTAX Definition
a SEMANTIC meaning!!

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

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


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

[ThSITC]

Hi Bill,
   1.) Thanks for your response.

   2.) Let me be a HUMAN programming newbie, an look at your sample program (copied from your message below), e.g.:

    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
          say  "Start (true)"
    ELSE
         say  "Start (false)"
    say  "Next"    -- Always executed

   3.) Now, I'm LOOKING (as a HUMAN programming newbie (*not* as Thomas Schneider), at your HUMAN program,
find it interesting, and do make one or two small modifications, for instance:

    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
          say  "Start (true)"
          say 'a was:' a
    ELSE
         say  "Start (false)"
         say 'b waqs:' b
    say  "Next"    -- Always executed    

Hope you GOT my point!

It's a LANGUAGE ASSYMETRY!
Thomas.
===================================================================

Am 18.11.2011 02:25, schrieb Bill Fenlason:

Thomas,

The issue of the difference between the end of line and a semicolon is a red herring in this discussion.

There are two approaches in defining the syntax for an IF construct.  The first uses an explicit ending (such as ENDIF or END something) and the second does not.  Either is sufficient.

NetRexx uses only the second form, and determines the end of the IF construct by finding the end of the ELSE instruction (or the THEN instruction if the ELSE clause is missing).  The THEN and ELSE instructions may be complex instructions, such as DO, LOOP, etc.   

Any attempt to add an optional explicit end to the existing NetRexx IF construct will add significant user error possibilities and reduce the clarity of the program structure.  Adding a mandatory end is out of the question because of breakage.

For example, the following is valid NetRexx and always results in two initial output lines
    ...
    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
         say  "Start (true)"
    ELSE
         say  "Start (false)"
    say  "Next"    -- Always executed   
    --  Many more statements
/* end of file */ 

If an optional explicit ending for the IF statement is added to NetRexx, consider the following:
    ...
    IF  a =  b  c   -- Note no semicolons or parens, and blank concatenate
    THEN
         say  "Start (true)"
    ELSE
          say  "Start (false)"
    say  "Next"    -- Unknown if this will be executed (requires look ahead)
    --  Many more statements
   END IF    -- If present, changes the program structure and execution
/* end of file */ 

Obviously that may be unexpected and confusing, and is contrary to the fundamental simplicity of Rexx.

Mike wrote the following in the language reference manual (emphasis mine):

"NetRexx is designed as a small language. It is not the sum of all the features of Rexx and of Java; rather, unnecessary features have been omitted. The intention has been to keep the language as small as possible, so that users can rapidly grasp most of the language. This means that:
    • the language appears less formidable to the new user
    • documentation is smaller and simpler
    • the experienced user can be aware of all the abilities of the language, and so has the whole tool at his or her disposal
    • there are few exceptions, special cases, or rarely used embellishments
    • the language is easier to implement.
Many languages have accreted “neat” features which make certain algorithms easier to express; analysis shows that many of these are rarely used. As a rough rule-of-thumb, features that simply provided alternative ways of writing code were added to Rexx and NetRexx only if they were likely to be used more often than once in five thousand clauses."

It would seem that adding unnecessary features to NetRexx should be strongly avoided.  In my opinion, that includes most of the currently suggested language extensions.  Java is a better solution if bells and whistles are desired.

Adding an explicit end to the NetRexx IF is clearly not needed, and it is unlikely that it will ever be added to standard NetRexx.  The concept is described in the language reference manual under "Limited span syntactic units".  The lack of an explicit end for an IF construct is most likely intentional.   While a dislike of DO ... END is understandable, an explicit end for the IF structure is not a viable replacement and would make NetRexx worse, not better.

Thomas, if you prefer a language that uses an explicit ending for an IF construct, perhaps you should stick to FORTRAN or any of the other languages that use that approach.  Note that Java does not.

As I suggested before, please implement and test your IF construct ideas in your own "NetRexx-like" language first, instead of continuing to suggest them here.  You are not "getting on my nerves", but it is a bit tiresome.  The horse was dead and buried long ago. 

Bill

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

[rvjansen]

Well you lost me, I don't get it. And, I always use do and end blocks,
and will force other people to do so if I am in a position to do so,
which I think give much more clarity and will save you from the next
programmer sticking in a line without seeing its place in the
if-then-else.

But our position on this must be, that any change will break so many
programs that it is of no use to think about this.

René.

On Fri, 18 Nov 2011 16:12:24 +0100, Thomas Schneider wrote:

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

[billfen]

Thomas,

In your example, you did not terminate the ELSE block so that "Next" is always output.  Are you also suggesting that indentation delimiters be added to NetRexx?

As I mentioned in my last note, the THEN and ELSE blocks must be delimited in some way.  You want the blocks to be delimited by the keywords and an explicit ENDIF.  NetRexx delimits them by restricting the blocks to a single instruction.

Like oil and water, these do not mix well.  FORTRAN has both logical and block IF constructs but it imposes syntactic conventions which are generally incompatible with NetRexx.  Other languages use curly braces or indentation, and neither of those would be appropriate for NetRexx either.

The basic IF construct in NetRexx is definitely not going to change, and a block IF cannot be added because of breakage. 

You can design and implement an IF construct for your own languages any way you want, but as Rene pointed out, suggesting impossible NetRexx language changes is of questionable value in this forum.

Bill

On 11/18/2011 10:12 AM, Thomas Schneider wrote:

Hi Bill,
   1.) Thanks for your response.

   2.) Let me be a HUMAN programming newbie, an look at your sample program (copied from your message below), e.g.:

    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
          say  "Start (true)"
    ELSE
         say  "Start (false)"
    say  "Next"    -- Always executed

   3.) Now, I'm LOOKING (as a HUMAN programming newbie (*not* as Thomas Schneider), at your HUMAN program,
find it interesting, and do make one or two small modifications, for instance:

    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
          say  "Start (true)"
          say 'a was:' a
    ELSE
         say  "Start (false)"
         say 'b waqs:' b
    say  "Next"    -- Always executed    

Hope you GOT my point!

It's a LANGUAGE ASSYMETRY!
Thomas.
===================================================================

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

[ThSITC]

Hello Bill, and all:

YES, I do think that an OPTIONS  -INDENT (defefault -NOINDENT, as it is now)
Would be the most easy to implement solution.

I'm currently in the process to finish my RexxForm (a Rexx Re-Formatter, using my own Rexx Parser (any Dialect
*should* be supported, including classic Rexx, ooRexx, Regina (ANSII Rexx), NetRexx, and Rey, my own (experimental)
language additions).

Les Koehler has been so nice to forward the THE Editor .profile variables for me, which should & will
allow to tailor the format to the individual needs.

I *personally*, however, for NetRexx (and also ooRexx, would go the OPTIONS -INDENT route.

This seems, for me, that what any NEWBIE for HUMAN oriented Languages would understand most easily.

Full-Stop.

As Rene suggested, I will give an ONLINE Demo whilst you are in ARUBA. Unfortunately, my budget
does NOT allow to come there.

Greetings,
Thomas.
=========================================================================================
Am 18.11.2011 17:58, schrieb Bill Fenlason:

Thomas,

In your example, you did not terminate the ELSE block so that "Next" is always output.  Are you also suggesting that indentation delimiters be added to NetRexx?

As I mentioned in my last note, the THEN and ELSE blocks must be delimited in some way.  You want the blocks to be delimited by the keywords and an explicit ENDIF.  NetRexx delimits them by restricting the blocks to a single instruction.

Like oil and water, these do not mix well.  FORTRAN has both logical and block IF constructs but it imposes syntactic conventions which are generally incompatible with NetRexx.  Other languages use curly braces or indentation, and neither of those would be appropriate for NetRexx either.

The basic IF construct in NetRexx is definitely not going to change, and a block IF cannot be added because of breakage. 

You can design and implement an IF construct for your own languages any way you want, but as Rene pointed out, suggesting impossible NetRexx language changes is of questionable value in this forum.

Bill

On 11/18/2011 10:12 AM, Thomas Schneider wrote:

Hi Bill,
   1.) Thanks for your response.

   2.) Let me be a HUMAN programming newbie, an look at your sample program (copied from your message below), e.g.:

    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
          say  "Start (true)"
    ELSE
         say  "Start (false)"
    say  "Next"    -- Always executed

   3.) Now, I'm LOOKING (as a HUMAN programming newbie (*not* as Thomas Schneider), at your HUMAN program,
find it interesting, and do make one or two small modifications, for instance:

    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
          say  "Start (true)"
          say 'a was:' a
    ELSE
         say  "Start (false)"
         say 'b waqs:' b
    say  "Next"    -- Always executed    

Hope you GOT my point!

It's a LANGUAGE ASSYMETRY!
Thomas.
===================================================================

_______________________________________________
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]

Bill,
You write

"There are two approaches in defining the syntax for an IF construct.  The first uses an explicit ending (such as ENDIF or END something) and the second does not.  Either is sufficient." (my emphasis)

I must most emphatically assert:  NOT SUFFICIENT.  You mean, I assume, that either suffices to express program logic.  But as I explained in my post of Nov 8 under "Introducing a Semantic Meaning of the Keyword THEN", the fundamental flaw in the "END-less" approach is making the consequent of a predicate a single statement.

As I demonstrated in my example, in a real-world maintenance environment this leads to programmers adding statements in the mistaken belief that all will execute only as a result of the predicate.  This is not some airy-fairy notion: I have seen it consume much time and money.  I deal with it by adopting a convention: if the consequent is not written on the same line as the predicate, it must be enclosed in DO...END, even if it is a single statement.  But why should I have to protect myself from NetRexx in this way?

I appreciate you are impatient with Thomas's creative proposals but the issue is deeper than "my personal preference is."  The single consequent approach conspires with unavoidable flaws in human make up to produce a bad result.  To wave the issue away strikes me as contrary to everything NetRexx stands for.

I exhibited FORTRAN's way because it shows others have dealt with this issue creatively and successfully.  However, you say it is impossible or impractical to adopt that way, and I bow to your experience.

Fixing this will strengthen NetRexx's claim to being a human-oriented language.  Therefore, I challenge you to devise a creative solution that allows the single- or multiple-consequent forms of IF to be coded in exactly the same way.  It should not depend on a convention.  It wouldn't necessarily have to use the keyword IF.

Regards,
George

On Thu, Nov 17, 2011 at 8:25 PM, Bill Fenlason <[hidden email]> wrote:

Thomas,

The issue of the difference between the end of line and a semicolon is a red herring in this discussion.

There are two approaches in defining the syntax for an IF construct.  The first uses an explicit ending (such as ENDIF or END something) and the second does not.  Either is sufficient.

NetRexx uses only the second form, and determines the end of the IF construct by finding the end of the ELSE instruction (or the THEN instruction if the ELSE clause is missing).  The THEN and ELSE instructions may be complex instructions, such as DO, LOOP, etc.   

Any attempt to add an optional explicit end to the existing NetRexx IF construct will add significant user error possibilities and reduce the clarity of the program structure.  Adding a mandatory end is out of the question because of breakage.

For example, the following is valid NetRexx and always results in two initial output lines
    ...
    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
         say  "Start (true)"
    ELSE
         say  "Start (false)"
    say  "Next"    -- Always executed   
    --  Many more statements
/* end of file */ 

If an optional explicit ending for the IF statement is added to NetRexx, consider the following:
    ...
    IF  a =  b  c   -- Note no semicolons or parens, and blank concatenate
    THEN
         say  "Start (true)"
    ELSE
          say  "Start (false)"
    say  "Next"    -- Unknown if this will be executed (requires look ahead)
    --  Many more statements
   END IF    -- If present, changes the program structure and execution
/* end of file */ 

Obviously that may be unexpected and confusing, and is contrary to the fundamental simplicity of Rexx.

Mike wrote the following in the language reference manual (emphasis mine):

"NetRexx is designed as a small language. It is not the sum of all the features of Rexx and of Java; rather, unnecessary features have been omitted. The intention has been to keep the language as small as possible, so that users can rapidly grasp most of the language. This means that:
    • the language appears less formidable to the new user
    • documentation is smaller and simpler
    • the experienced user can be aware of all the abilities of the language, and so has the whole tool at his or her disposal
    • there are few exceptions, special cases, or rarely used embellishments
    • the language is easier to implement.
Many languages have accreted “neat” features which make certain algorithms easier to express; analysis shows that many of these are rarely used. As a rough rule-of-thumb, features that simply provided alternative ways of writing code were added to Rexx and NetRexx only if they were likely to be used more often than once in five thousand clauses."

It would seem that adding unnecessary features to NetRexx should be strongly avoided.  In my opinion, that includes most of the currently suggested language extensions.  Java is a better solution if bells and whistles are desired.

Adding an explicit end to the NetRexx IF is clearly not needed, and it is unlikely that it will ever be added to standard NetRexx.  The concept is described in the language reference manual under "Limited span syntactic units".  The lack of an explicit end for an IF construct is most likely intentional.   While a dislike of DO ... END is understandable, an explicit end for the IF structure is not a viable replacement and would make NetRexx worse, not better.

Thomas, if you prefer a language that uses an explicit ending for an IF construct, perhaps you should stick to FORTRAN or any of the other languages that use that approach.  Note that Java does not.

As I suggested before, please implement and test your IF construct ideas in your own "NetRexx-like" language first, instead of continuing to suggest them here.  You are not "getting on my nerves", but it is a bit tiresome.  The horse was dead and buried long ago. 

Bill

_______________________________________________
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]

George wrote ...

 

 Fixing this will strengthen NetRexx's claim to being a human-oriented language.  Therefore, I challenge you to devise a creative solution that allows the single- or multiple-consequent forms of IF to be coded in exactly the same way.  It should not depend on a convention.  It wouldn't necessarily have to use the keyword IF.
 

I did, in truth, spend a great deal of time experimenting with many different flavours of conditional statements, including IF..FI, various kinds of ENDIF, and some novel forms too (including just using indention, as Python does today, and a rather nice IS construct, which I still have notes on, somewhere).  

 

In practice they all have flaws, and none are wholly intuitive -- because human language is generally imprecise in this kind of area.   IF ... FI and IF ... ENDIF were particularly confusing to new users because they have no parallel in everyday language constructs; I suspect they were introduced mostly to make parsers easier to write rather than to help users learn to program.

 

In contrast, in verbal forms, stress of various kinds is used to indicate the beginning and end of a 'group' of related items or actions, and DO-END codifies that in a reasonably concise and understandable way.   It would be nice to use fonts or colour instead, perhaps, but programmers seem to be too conservative to accept that approach.

 

The structure of IF - THEN in Rexx and NetRexx also fits nicely with the SELECT construct .. a series of IF .. THEN .. ELSE IF ... statements is easily converted to a SELECT list, with just a few changes of keyword.

 

And something I do feel strongly about is the ability to put a label on an END clause -- this hugely improves readability when a construct takes more than one screen or page.

 

In Rexx I made the mistake of using DO for both groups and loops -- but that has been fixed in NetRexx.

 

Mike 

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

[Aviatrexx]

Being perfectly happy with the Rexx/NetRexx I-T-E construct, I
hesitate to contribute to this discussion at all.

OTOH... :-)

Would it be reasonable to recognize a colon (:) token at the beginning
of a clause as a "Do-End group" connector?

   If a = 5 Then Say "a = 5"       -- same as
   Else Say "a \= 5"               --   always
   If foo Then Say "foo is true"   -- implicit do-end containing
     : foo = 0                     --   three statements executed as
     : bar = 1                     --   a 'then' clause
   If baz = 0 Then
     Say "baz is zero"
   Else
     Say "baz was not zero" : baz = 0 : Say "but it is now"

Conceptually, it would be a continuation character limited to the
scope of the Then and Else keywords of the I-T-E and S-W-O constructs.

Lexically, it would be not be confused with a label because it lacks a
preceding symbol.

Comments?

-Chip-

On 11/18/11 20:50 Mike Cowlishaw said:

> George wrote ...
>> Fixing this will strengthen NetRexx's claim to being a
>> human-oriented language.  Therefore, I challenge you to devise a
>> creative solution that allows the single- or multiple-consequent
>> forms of IF to be coded in exactly the same way.  It should not
>> depend on a convention.  It wouldn't necessarily have to use the
>> keyword IF.
>
> I did, in truth, spend a great deal of time experimenting with many
> different flavours of conditional statements, including IF..FI,
> various kinds of ENDIF, and some novel forms too (including
> just using indention, as Python does today, and a rather nice IS
> construct, which I still have notes on, somewhere).  

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

[Kermit Kiser]

While I still think that changing the IF instruction would create a mess and break existing programs, that is not the case for the SELECT instruction. I agree with those who think that SELECT is inconsistent and confusing. I just ran some tests and examined the documentation and I am sure that we can fix SELECT without breaking any existing programs.

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

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!):

true= boolean 1

false=boolean 0

condition1=true

select

    when condition1=true

        say "true #1"

        say "true #2"

    when condition1=false

        say "false #1"

        say "false #2"
 end

Does anyone see any problem with this approach?

-- Kermit


On 11/18/2011 11:39 AM, George Hovey wrote:

Bill,
You write

"There are two approaches in defining the syntax for an IF construct.  The first uses an explicit ending (such as ENDIF or END something) and the second does not.  Either is sufficient." (my emphasis)

I must most emphatically assert:  NOT SUFFICIENT.  You mean, I assume, that either suffices to express program logic.  But as I explained in my post of Nov 8 under "Introducing a Semantic Meaning of the Keyword THEN", the fundamental flaw in the "END-less" approach is making the consequent of a predicate a single statement.

As I demonstrated in my example, in a real-world maintenance environment this leads to programmers adding statements in the mistaken belief that all will execute only as a result of the predicate.  This is not some airy-fairy notion: I have seen it consume much time and money.  I deal with it by adopting a convention: if the consequent is not written on the same line as the predicate, it must be enclosed in DO...END, even if it is a single statement.  But why should I have to protect myself from NetRexx in this way?

I appreciate you are impatient with Thomas's creative proposals but the issue is deeper than "my personal preference is."  The single consequent approach conspires with unavoidable flaws in human make up to produce a bad result.  To wave the issue away strikes me as contrary to everything NetRexx stands for.

I exhibited FORTRAN's way because it shows others have dealt with this issue creatively and successfully.  However, you say it is impossible or impractical to adopt that way, and I bow to your experience.

Fixing this will strengthen NetRexx's claim to being a human-oriented language.  Therefore, I challenge you to devise a creative solution that allows the single- or multiple-consequent forms of IF to be coded in exactly the same way.  It should not depend on a convention.  It wouldn't necessarily have to use the keyword IF.

Regards,
George

On Thu, Nov 17, 2011 at 8:25 PM, Bill Fenlason <[hidden email]> wrote:

Thomas,

The issue of the difference between the end of line and a semicolon is a red herring in this discussion.

There are two approaches in defining the syntax for an IF construct.  The first uses an explicit ending (such as ENDIF or END something) and the second does not.  Either is sufficient.

NetRexx uses only the second form, and determines the end of the IF construct by finding the end of the ELSE instruction (or the THEN instruction if the ELSE clause is missing).  The THEN and ELSE instructions may be complex instructions, such as DO, LOOP, etc.   

Any attempt to add an optional explicit end to the existing NetRexx IF construct will add significant user error possibilities and reduce the clarity of the program structure.  Adding a mandatory end is out of the question because of breakage.

For example, the following is valid NetRexx and always results in two initial output lines
    ...
    IF  a =  b  c    -- Note no semicolons or parens, and blank concatenate
    THEN
         say  "Start (true)"
    ELSE
         say  "Start (false)"
    say  "Next"    -- Always executed   
    --  Many more statements
/* end of file */ 

If an optional explicit ending for the IF statement is added to NetRexx, consider the following:
    ...
    IF  a =  b  c   -- Note no semicolons or parens, and blank concatenate
    THEN
         say  "Start (true)"
    ELSE
          say  "Start (false)"
    say  "Next"    -- Unknown if this will be executed (requires look ahead)
    --  Many more statements
   END IF    -- If present, changes the program structure and execution
/* end of file */ 

Obviously that may be unexpected and confusing, and is contrary to the fundamental simplicity of Rexx.

Mike wrote the following in the language reference manual (emphasis mine):

"NetRexx is designed as a small language. It is not the sum of all the features of Rexx and of Java; rather, unnecessary features have been omitted. The intention has been to keep the language as small as possible, so that users can rapidly grasp most of the language. This means that:
    • the language appears less formidable to the new user
    • documentation is smaller and simpler
    • the experienced user can be aware of all the abilities of the language, and so has the whole tool at his or her disposal
    • there are few exceptions, special cases, or rarely used embellishments
    • the language is easier to implement.
Many languages have accreted “neat” features which make certain algorithms easier to express; analysis shows that many of these are rarely used. As a rough rule-of-thumb, features that simply provided alternative ways of writing code were added to Rexx and NetRexx only if they were likely to be used more often than once in five thousand clauses."

It would seem that adding unnecessary features to NetRexx should be strongly avoided.  In my opinion, that includes most of the currently suggested language extensions.  Java is a better solution if bells and whistles are desired.

Adding an explicit end to the NetRexx IF is clearly not needed, and it is unlikely that it will ever be added to standard NetRexx.  The concept is described in the language reference manual under "Limited span syntactic units".  The lack of an explicit end for an IF construct is most likely intentional.   While a dislike of DO ... END is understandable, an explicit end for the IF structure is not a viable replacement and would make NetRexx worse, not better.

Thomas, if you prefer a language that uses an explicit ending for an IF construct, perhaps you should stick to FORTRAN or any of the other languages that use that approach.  Note that Java does not.

As I suggested before, please implement and test your IF construct ideas in your own "NetRexx-like" language first, instead of continuing to suggest them here.  You are not "getting on my nerves", but it is a bit tiresome.  The horse was dead and buried long ago. 

Bill

_______________________________________________
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]

In a SELECT statement, I'm NOT in favor of making the THEN keyword optional.

I don't think recognizing line ends or semicolons should be used to delimit blocks or to separate the sequence of expressions from the associated instruction(s).  I don't think there are any other cases where a keyword (necessary for program structure) is made optional, and I don't think that precedent should be set.  It might cause problems with source processing programs (reformatters, etc.), and also negatively impact parsing in general.

I have mixed feelings about replacing the THEN instruction (in a SELECT) with a block of one or more instructions.  On the one hand is adds consistency with the other blocks within a SELECT, but on the other hand it seems to violate the principle of "Limited Span Syntactic Units".  It could also complicate parsing in some situations because of the required look ahead.

The "IF expression THEN instruction" and the "WHEN expression THEN instruction" are congruous, and if the THEN instruction in a SELECT is changed to a block, one could reasonably ask "why not do the same for IF ?" and we have already seen what a slippery slope that is.

But back on the first hand, to me, there is little difference between:
    SELECT
        WHEN  a  THEN 
            x  =  1
        WHEN  b  THEN
             x  =  2
        OTHERWISE
            x  =  3
    END

and the FORTRAN sequence of
   
    IF  ( a )  THEN 
        x  =  1
     ELSE IF  ( b )  THEN
        x  =  2
    ELSE
        x  =  3
    END IF

so, if the SELECT  THEN instruction is replaced with a block, those who want an IF construct with an explicit end should be at least partially satisfied.  But as I said, I'm still on the fence with it.

Bill

On 11/18/2011 6:59 PM, Kermit Kiser wrote:

While I still think that changing the IF instruction would create a mess and break existing programs, that is not the case for the SELECT instruction. I agree with those who think that SELECT is inconsistent and confusing. I just ran some tests and examined the documentation and I am sure that we can fix SELECT without breaking any existing programs.

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

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!):

true= boolean 1

false=boolean 0

condition1=true

select

    when condition1=true

        say "true #1"

        say "true #2"

    when condition1=false

        say "false #1"

        say "false #2"
 end

Does anyone see any problem with this approach?

-- Kermit624 - Release Date: 11/18/11

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

[George Hovey-2]

Chip,
I can't evaluate your solution (others soon will!) but thanks for taking the issue seriously.
George

On Fri, Nov 18, 2011 at 6:03 PM, Chip Davis <[hidden email]> wrote:

Being perfectly happy with the Rexx/NetRexx I-T-E construct, I hesitate to contribute to this discussion at all.

OTOH... :-)

Would it be reasonable to recognize a colon (:) token at the beginning of a clause as a "Do-End group" connector?

 If a = 5 Then Say "a = 5"       -- same as
 Else Say "a \= 5"               --   always
 If foo Then Say "foo is true"   -- implicit do-end containing
   : foo = 0                     --   three statements executed as
   : bar = 1                     --   a 'then' clause
 If baz = 0 Then
   Say "baz is zero"
 Else
   Say "baz was not zero" : baz = 0 : Say "but it is now"

Conceptually, it would be a continuation character limited to the scope of the Then and Else keywords of the I-T-E and S-W-O constructs.

Lexically, it would be not be confused with a label because it lacks a preceding symbol.

Comments?

-Chip-

On 11/18/11 20:50 Mike Cowlishaw said:

George wrote ...

Fixing this will strengthen NetRexx's claim to being a
human-oriented language.  Therefore, I challenge you to devise a
creative solution that allows the single- or multiple-consequent
forms of IF to be coded in exactly the same way.  It should not
depend on a convention.  It wouldn't necessarily have to use the
keyword IF.

I did, in truth, spend a great deal of time experimenting with many
different flavours of conditional statements, including IF..FI,
various kinds of ENDIF, and some novel forms too (including
just using indention, as Python does today, and a rather nice IS
construct, which I still have notes on, somewhere).  

_______________________________________________
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]

Chip,
I think the colon should be reserved for another (yet undetermined) use.

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

If one insists on having THEN and ELSE blocks in NetRexx, the most
straight forward and humanly readable approach is DO ... END.

The most concise approach is curly brackets, and I think that few people
want to go that route.


On 11/18/2011 6:03 PM, Chip Davis wrote:

> Being perfectly happy with the Rexx/NetRexx I-T-E construct, I
> hesitate to contribute to this discussion at all.
>
> OTOH... :-)
>
> Would it be reasonable to recognize a colon (:) token at the beginning
> of a clause as a "Do-End group" connector?
>
>   If a = 5 Then Say "a = 5"       -- same as
>   Else Say "a \= 5"               --   always
>   If foo Then Say "foo is true"   -- implicit do-end containing
>     : foo = 0                     --   three statements executed as
>     : bar = 1                     --   a 'then' clause
>   If baz = 0 Then
>     Say "baz is zero"
>   Else
>     Say "baz was not zero" : baz = 0 : Say "but it is now"
>
> Conceptually, it would be a continuation character limited to the
> scope of the Then and Else keywords of the I-T-E and S-W-O constructs.
>
> Lexically, it would be not be confused with a label because it lacks a
> preceding symbol.
>
> Comments?
>
> -Chip-
>
> On 11/18/11 20:50 Mike Cowlishaw said:
>> George wrote ...
>>> Fixing this will strengthen NetRexx's claim to being a
>>> human-oriented language.  Therefore, I challenge you to devise a
>>> creative solution that allows the single- or multiple-consequent
>>> forms of IF to be coded in exactly the same way.  It should not
>>> depend on a convention.  It wouldn't necessarily have to use the
>>> keyword IF.
>>
>> I did, in truth, spend a great deal of time experimenting with many
>> different flavours of conditional statements, including IF..FI,
>> various kinds of ENDIF, and some novel forms too (including
>> just using indention, as Python does today, and a rather nice IS
>> construct, which I still have notes on, somewhere).
>
> _______________________________________________
> 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: 2092/4624 - Release Date: 11/18/11
>
>

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

[Tom Maynard]

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/

[Kermit Kiser]

Bill -

I don't follow your logic. In NRL, both the IF and SELECT descriptions contain this identical note:

2. The keyword then is treated specially, in that it need not start a clause. This allows the
expression on the if clause to be terminated by the then, without a “;” being required – were
this not so, people used to other computer languages would be inconvenienced. Hence the
symbol then cannot be used as a variable name within the expression.

In other words, the keyword THEN is being treated in a special way to allow the expression in the IF or WHEN to be terminated without a semi-colon or line end as is normally required to end an expression. That means the semi-colon/line end/THEN keyword are being used to end the expression, not to start anything. And it is clear from the OTHERWISE/CATCH/FINALLY structures which now accept multiple instructions that no THEN keyword is required to initiate an implied DO...END block, so THEN cannot be considered "necessary for program structure".  I suspect that Mike only put THEN in the WHEN construct to make it look more like an IF statement for easier language learning and for ease in converting sequences of IF statements to SELECT statements.

I do not see any concerns about parsing and "Limited Span" since they do not seem to impact the existing OTHERWISE/CATCH/FINALLY constructs negatively.

Likewise I don't understand your question "why not do the same for IF ?", because the SELECT construct has a well defined END delimiter which the IF statement does not, making them quite different situations which cannot be trivially compared. SELECT can easily be made consistent without adding keywords or damaging existing programs because the group delimiters already exist, while IF...ELSEIF...ENDIF is going to be a problem because there is no current way to delimit an instruction block in an IF statement without DO...END statements and adding one will break existing stuff.

-- Kermit

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.


On 11/18/2011 6:04 PM, Bill Fenlason wrote:

In a SELECT statement, I'm NOT in favor of making the THEN keyword optional.

I don't think recognizing line ends or semicolons should be used to delimit blocks or to separate the sequence of expressions from the associated instruction(s).  I don't think there are any other cases where a keyword (necessary for program structure) is made optional, and I don't think that precedent should be set.  It might cause problems with source processing programs (reformatters, etc.), and also negatively impact parsing in general.

I have mixed feelings about replacing the THEN instruction (in a SELECT) with a block of one or more instructions.  On the one hand is adds consistency with the other blocks within a SELECT, but on the other hand it seems to violate the principle of "Limited Span Syntactic Units".  It could also complicate parsing in some situations because of the required look ahead.

The "IF expression THEN instruction" and the "WHEN expression THEN instruction" are congruous, and if the THEN instruction in a SELECT is changed to a block, one could reasonably ask "why not do the same for IF ?" and we have already seen what a slippery slope that is.

But back on the first hand, to me, there is little difference between:
    SELECT
        WHEN  a  THEN 
            x  =  1
        WHEN  b  THEN
             x  =  2
        OTHERWISE
            x  =  3
    END

and the FORTRAN sequence of
   
    IF  ( a )  THEN 
        x  =  1
     ELSE IF  ( b )  THEN
        x  =  2
    ELSE
        x  =  3
    END IF

so, if the SELECT  THEN instruction is replaced with a block, those who want an IF construct with an explicit end should be at least partially satisfied.  But as I said, I'm still on the fence with it.

Bill

On 11/18/2011 6:59 PM, Kermit Kiser wrote:

While I still think that changing the IF instruction would create a mess and break existing programs, that is not the case for the SELECT instruction. I agree with those who think that SELECT is inconsistent and confusing. I just ran some tests and examined the documentation and I am sure that we can fix SELECT without breaking any existing programs.

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

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!):

true= boolean 1

false=boolean 0

condition1=true

select

    when condition1=true

        say "true #1"

        say "true #2"

    when condition1=false

        say "false #1"

        say "false #2"
 end

Does anyone see any problem with this approach?

-- Kermit624 - Release Date: 11/18/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/

[Rony G. Flatscher (wu-wien)]

A DO keyword instruction is logically a single statement. It just happens to encompass as many statements as one sees a need for to be executed together. The keyword instruction is defined such that it has to be concluded with the END subkeyword.

The SELECT keyword instruction may consist of the subkeyword instructions "WHEN boolean THEN instruction" and optionally "OTHERWISE instructionS" (pleasae note the plural form).

The subkeywords "CATCH instructionS" (please note plural) and "FINALLY instructionS" (please note plural) are not instructions per se but are defined in the context of the DO-, LOOP- and SELECT-instructions.

Ad: "the simple rule that in the case that multiple instructions should logically be treated as a single instruction by using a DO-instruction is "broken" for the subkeywords OTHERWISE/CATCH/FINALLY." NOT! This is a question of concepts, how one looks at these subkeyword instructions. As these are subkeywords their syntax is defined by the instruction that allows them. The ultimate source for how to look at these constructs is definitely the language definition and the language documentation, *not* the personal preferences one has built using/looking into different languages, with different paradigms.

Reading the NetRexx documentation this would be the view I would expect people to take on:

• the SELECT-instruction is structured such, that it consists of tests introduced with the WHEN-subkeyword followed by a single instruction and optionally (!) followed by a default section of instructions to be carried out, if none of the WHEN tests succeeded. Clealry, the documentation states that multiple  instructions may follow the OTHERWISE subkeyword.
  
  
• the DO-/LOOP-/SELECT-instructions can be structured and have an optional (!) CATCH-clause followed by instructions (please note the plural) and an optional (!) FINALLY-clause followed by instructions (please note the plural). The documentation seems to be very clear here as well.
  

Probably reading the NetRexx documentation and the principles of the NetRexx language from time to time becomes important, as over time, especially if working in/with other languages, the core concepts, that make NetRexx easy to learn, easy to use and small, may fade away such that concepts of other languages are superimposed on NetRexx, potentially destroying its uniqueness that originally has drawn so many fine people to the language.

---

Ad definitions for the THEN subkeyword:

• after a THEN subkeyword a single instruction must follow; hence, if one needs multiple instructions, then one needs to apply the DO-instruction to achieve that,
• the position of the THEN-subkeyword and the position of the instruction, which allows one to format the section of "THEN instruction" are defined specially such, that they can be formatted extremely freely, like:
  
  

  if a=1          /* the next line belongs to the if-instruction, but must be a then-subkeyword */
  then            /* the next instruction belongs to the if-instruction's then-subkeyword and must be a single instruction */
  say "a=1"
  
  
  if a=2          /* the next line belongs to the if-instruction, but must be a then-subkeyword */
  then say "a=2"
  
  
  if a=3 then     /* the next instruction belongs to the if-instruction's then-subkeyword and must be a single instruction */
   
     say "a=3"
  
  
  if a<>1 & a<>2 then say "a<>1 & a<>2"
  

However, the if-instruction is simply defined: "if boolean then instruction", hence the need of a do-instruction in case more than one instruction should get executed as a block. So is the WHEN-subkeyword instruction: "when boolean then instruction", allowing one to freely place the then-subkeyword as depicted with the if-instruction above.

It seems to me that these are simple, i.e. easy to remember rules, with no inconsistencies.

---rony







On 19.11.2011 09:51, Kermit Kiser wrote:

Bill -

I don't follow your logic. In NRL, both the IF and SELECT descriptions contain this identical note:

2. The keyword then is treated specially, in that it need not start a clause. This allows the
expression on the if clause to be terminated by the then, without a “;” being required – were
this not so, people used to other computer languages would be inconvenienced. Hence the
symbol then cannot be used as a variable name within the expression.

In other words, the keyword THEN is being treated in a special way to allow the expression in the IF or WHEN to be terminated without a semi-colon or line end as is normally required to end an expression. That means the semi-colon/line end/THEN keyword are being used to end the expression, not to start anything. And it is clear from the OTHERWISE/CATCH/FINALLY structures which now accept multiple instructions that no THEN keyword is required to initiate an implied DO...END block, so THEN cannot be considered "necessary for program structure".  I suspect that Mike only put THEN in the WHEN construct to make it look more like an IF statement for easier language learning and for ease in converting sequences of IF statements to SELECT statements.

I do not see any concerns about parsing and "Limited Span" since they do not seem to impact the existing OTHERWISE/CATCH/FINALLY constructs negatively.

Likewise I don't understand your question "why not do the same for IF ?", because the SELECT construct has a well defined END delimiter which the IF statement does not, making them quite different situations which cannot be trivially compared. SELECT can easily be made consistent without adding keywords or damaging existing programs because the group delimiters already exist, while IF...ELSEIF...ENDIF is going to be a problem because there is no current way to delimit an instruction block in an IF statement without DO...END statements and adding one will break existing stuff.

-- Kermit

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.


On 11/18/2011 6:04 PM, Bill Fenlason wrote:

In a SELECT statement, I'm NOT in favor of making the THEN keyword optional.

I don't think recognizing line ends or semicolons should be used to delimit blocks or to separate the sequence of expressions from the associated instruction(s).  I don't think there are any other cases where a keyword (necessary for program structure) is made optional, and I don't think that precedent should be set.  It might cause problems with source processing programs (reformatters, etc.), and also negatively impact parsing in general.

I have mixed feelings about replacing the THEN instruction (in a SELECT) with a block of one or more instructions.  On the one hand is adds consistency with the other blocks within a SELECT, but on the other hand it seems to violate the principle of "Limited Span Syntactic Units".  It could also complicate parsing in some situations because of the required look ahead.

The "IF expression THEN instruction" and the "WHEN expression THEN instruction" are congruous, and if the THEN instruction in a SELECT is changed to a block, one could reasonably ask "why not do the same for IF ?" and we have already seen what a slippery slope that is.

But back on the first hand, to me, there is little difference between:
    SELECT
        WHEN  a  THEN 
            x  =  1
        WHEN  b  THEN
             x  =  2
        OTHERWISE
            x  =  3
    END

and the FORTRAN sequence of
   
    IF  ( a )  THEN 
        x  =  1
     ELSE IF  ( b )  THEN
        x  =  2
    ELSE
        x  =  3
    END IF

so, if the SELECT  THEN instruction is replaced with a block, those who want an IF construct with an explicit end should be at least partially satisfied.  But as I said, I'm still on the fence with it.

Bill

On 11/18/2011 6:59 PM, Kermit Kiser wrote:

While I still think that changing the IF instruction would create a mess and break existing programs, that is not the case for the SELECT instruction. I agree with those who think that SELECT is inconsistent and confusing. I just ran some tests and examined the documentation and I am sure that we can fix SELECT without breaking any existing programs.

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

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!):

true= boolean 1

false=boolean 0

condition1=true

select

    when condition1=true

        say "true #1"

        say "true #2"

    when condition1=false

        say "false #1"

        say "false #2"
 end

Does anyone see any problem with this approach?

-- Kermit624 - Release Date: 11/18/11

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

[Mike Cowlishaw]

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.

[Sorry about the bars to the left, btw -- darned if I can find out how to get Outlook to remove them... anyone know how?] 
 

------------- 

 

 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.

 

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

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 

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

[Mike Cowlishaw]

Rony's post reminded me of another proposal I had for Rexx circa 1979: allow clauses before the first WHEN in SELECT, so that (for example):

 

 

if foo=bar then select

   foocount=foocount+1

   when foo=1 then do

     aaa

     bbb

     end

   when foo=0 then whatever

   end -- select

 

again, the argument against this was lack or redundancy -- and maybe consistency with PL/I -- but perhaps this is worth revisiting.   Allowing then before subsequent WHENs (as in previous post) would be even more resonable, then.

 

Mike

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