Proposed NetRexx Language improvements

[Thomas.Schneider.Wien]

  Hello there,

    as I did not get any answer where to address these issues on, I will
now start
to make this conversation ONLINE on this group.

    First, I must admit, that NetRexx is perfectly designed :-)

    Second, as I cannot usee attached files, I am simply typing it in
here :-(

    Third,  I do have a (personal) wish-list:

all opinions are personal opinions of course, but I'm throwing them now
in as an input for NetRexx 3
)

1.) Syntax and semantics of the end statement.

     The 'end' clause should allow an optionional argument to say 'what
do I end' , e.g.

     select case a
        when 'abc' then ...
        when 'def' then ...
        otherwise ...
     end select ...

      This would make the usage of Notes (line comments) at the end
unnecessary.

    Semantics: If any structured clauses before this 'qualified' end are
NOT yet closed explicitely,
my personal opinion is: The should be closed implicitely (probably with
a warning).

2.) The USES clause in a CLASS statement should cause, that all proper
properties
of this class are not only recognized as properties of this class on the
RIGHT hand side of an Assignment
(or as Arguments of a method invocation), but also ON THE LEFT HAND Side
of an assignment.

As far as I can see it, the current reference implementation is
incorrect (when looking at the definition of a term)
(Sorry, Mike, to say that :-( )

For example:

       class ReyScan uses ReyMsg, ReyFile

           if (ic1 > 7) then error('this is an error')

does work perfectly well (as ic1 is a public property of ReyMsg,
defining the current parse Position)

*BUT*

          ic1 = 18

*does NOT have the desired effet, to set the *used* property of ReyMsg
to seven (7),
it does create a *new* variable (without any warning)

I did discuss this with Mike years ago, and I do *not* like to repeat
this discussion, but

*** it is ridiculous, when a simple symbol in te same program has two
totally different meanings ***

I will continue to throw in (SIGNAL) proposals for NetRexx 3 under this
thread, as I would like to
raise *this discussion here*  (as no t been advised to raise it elsewhere)

Thomas Schneider.

www.thsitc.com
www.Rexx2Nrx.com
www.db-123.com

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

 

> 1.) Syntax and semantics of the end statement.
>
>      The 'end' clause should allow an optionional argument to
> say 'what do I end' , e.g.
>
>      select case a
>         when 'abc' then ...
>         when 'def' then ...
>         otherwise ...
>      end select ...
>
>       This would make the usage of Notes (line comments) at
> the end unnecessary.

This is already there -- the syntax is:

      select label chooser case a
         when 'abc' then ...
         when 'def' then ...
         otherwise ...
      end chooser

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Robert L Hamilton]

In TnRL 2.0 it's on pp. 116-17 I think.

bobh

On Thu, Aug 26, 2010 at 1:57 AM, Mike Cowlishaw <[hidden email]> wrote:

> 1.) Syntax and semantics of the end statement.
>
>      The 'end' clause should allow an optionional argument to
> say 'what do I end' , e.g.
>
>      select case a
>         when 'abc' then ...
>         when 'def' then ...
>         otherwise ...
>      end select ...
>
>       This would make the usage of Notes (line comments) at
> the end unnecessary.

This is already there -- the syntax is:

     select label chooser case a

        when 'abc' then ...
        when 'def' then ...
        otherwise ...

     end chooser

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 26/08/2010 3:51, Thomas Schneider escribió:

2.) The USES clause in a CLASS statement should cause, that all proper properties
of this class are not only recognized as properties of this class on the RIGHT hand side of an Assignment
(or as Arguments of a method invocation), but also ON THE LEFT HAND Side of an assignment.

USES is indeed a somewhat 'strange' instruction. I guess it was included in the language
mainly to support the REXX function call model. In this light, using USES for anything else
would be somehow abusing the instruction..

*BUT*

         ic1 = 18

*does NOT have the desired effet, to set the *used* property of ReyMsg to seven (7),

That would indeed be surprising! :-)
Guess you meant '18' instead of '7'?

it does create a *new* variable (without any warning)

And that makes perfect sense to me. It is consistent with the regular access model
for inherited properties for example.

- You access a property, you got it.
- You define a variable with the same name as an inherited property, it hides the former.

What if you really wanted a new variable of a different type in your method? Say

    icl1 = boolean

You'd need a means of expressly refer to the given used class property if you needed both.
But you already have this mean.

    icl1 = 1  -- variable
    ReyMsg.icl1 = 18  -- used property

Which also addresses the issue of several used classes having same-named members. USES
gives unqualified access just to the first class having it among the ones in the uses-list.

Note that same thing applies to method invocations. In this case no assignment can be
done to a method but any used method can be hidden just by defining a same-signature
method in the present class.

That said, it could be worth considering the emission of a warning along the lines of
'Variable hides a used class' property'.

*** it is ridiculous, when a simple symbol in te same program has two totally different meanings ***

But it never does!
Up to the point where you re-define it, the symbol represents the used class' property.
From then on, it represents the new variable.

If you don't want that behaviour, well, just modify these used classes' properties by
using their qualified names. That will give you access to properties in any class on
uses-list regardless of their names. It will also make your code much more understandable
for any future reader/maintainer :-)





_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[FreeFall]

Is this an academic exercise, or is there a real prospect of creating a definition of new version of NetRexx, and a likelihood of it being implemented?   

On the question of end clauses, I could recommend the solution used in Tabetha 1.  A Tabetha program is not considered by the parser to be a single long string, but a two dimensional representation on paper, just as the programmer sees it.   In a conventional program, which clauses are linked to which statements is represented in two different ways:

1. Indentation, for the benefit of the human.
2. Statement...end pair of tokens for the parser.

Given that Tabetha is designed for the benefit of the human, the Tabetha 1 parser solely uses the method designed for the benefit of the human.   It uses the indentation of each line to establish which clauses belong to which statements.   As a result:

1. The 'end' clause becomes redundant.   Since end clauses consume a significant proportion of source vertical space, this helps Tabetha programs to be more concise, increasing the number of complete sections of code that can be visible in a single window (and hence avoiding bugs where two inconsistent statements are never displayed in the same window). 
2. A programmer using a conventional language can lead himself astray by using correct indentation, but incorrect ends (and elses).  This possibility for error is removed in Tabetha; if the nesting looks right, it is right!   Hence Tabetha programs will have fewer bugs than conventional programs.

This same idea could be adopted by a new version of NetRexx.   

Tabetha 2 went on to a better method still, but a bigger leap from today's NetRexx. 

If this is not just an academic exercise, why not implement Tabetha 2, calling it NetRexx 3?   They are ideologically similar, and indeed, if Tabetha 2 were to be implemented, the easiest way to do it would be to produce a translator to turn Tabetha programs into NetRexx!   NB, Tabetha 2 requires a more sophisticated editor than those used for conventional programming languages.   

Connor.

On 26 Aug 2010, at 07:57, Mike Cowlishaw wrote:

1.) Syntax and semantics of the end statement.

   The 'end' clause should allow an optionional argument to 

say 'what do I end' , e.g.

   select case a

      when 'abc' then ...

      when 'def' then ...

      otherwise ...

   end select ...

    This would make the usage of Notes (line comments) at 

the end unnecessary.

This is already there -- the syntax is:

    select label chooser case a

       when 'abc' then ...

       when 'def' then ...

       otherwise ...

    end chooser

Mike

_______________________________________________

Ibm-netrexx mailing list

[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Marc Remes]

Any 'improvement' should maintain backwards compatibility.

>>3.) The Note (line comment) delimiter should be re-specified as beeing  '(blank)--(blank)'
will break existing programs

>>4.) Assertions: x=13+14 --:<=27
may break existing programs

Best regards

Marc Remes

IBM Certified IT Specialist
IBM Global Technology Services
Mobile: [phone]
mailto:mremes@...



Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above:

International Business Machines of Belgium sprl / bvba
Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel
N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
RPM Bruxelles / RPR Brussel
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Ok, then which syntax for assertions would you propose ?

I originally did use
    x=13+14 ::<=27

But this would meen that the current NetRexx Compiler cannot be used, thus I thought
'enhancing' the note (by using --:) to denote assertions and introduce option assert
would be a viable solution.

Thomas.



Am 27.08.2010 13:58, schrieb Marc Remes:

Any 'improvement' should maintain backwards compatibility.

>>3.) The Note (line comment) delimiter should be re-specified as beeing  '(blank)--(blank)'
will break existing programs

>>4.) Assertions: x=13+14 --:<=27
may break existing programs

Best regards

Marc Remes

IBM Certified IT Specialist
IBM Global Technology Services
Mobile: [phone]
[hidden email]



Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above:

International Business Machines of Belgium sprl / bvba
Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel
N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
RPM Bruxelles / RPR Brussel

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[measel]

Not needed.  If you want assertions then in the nrx code use assertions as comments and use the –java option with nrc.  Quick replace of “— assert” and recompile with javac.

 

Question – who would want assertions in their scripts ?   Pedantic.

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Thomas Schneider
Sent: Friday, August 27, 2010 7:41 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Assertions -- was Proposed NetRexx Languageimprovements

 

Ok, then which syntax for assertions would you propose ?

I originally did use
    x=13+14 ::<=27

But this would meen that the current NetRexx Compiler cannot be used, thus I thought
'enhancing' the note (by using --:) to denote assertions and introduce option assert
would be a viable solution.

Thomas.



Am 27.08.2010 13:58, schrieb Marc Remes:

Any 'improvement' should maintain backwards compatibility.

>>3.) The Note (line comment) delimiter should be re-specified as beeing  '(blank)--(blank)'
will break existing programs

>>4.) Assertions: x=13+14 --:<=27
may break existing programs

Best regards

Marc Remes

IBM Certified IT Specialist
IBM Global Technology Services
Mobile: [phone]
[hidden email]



Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above:

International Business Machines of Belgium sprl / bvba
Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel
N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
RPM Bruxelles / RPR Brussel

_______________________________________________

Ibm-netrexx mailing list

[hidden email]

 

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

On the question of end clauses, I could recommend the solution used in Tabetha 1.  A Tabetha program is not considered by the parser to be a single long string, but a two dimensional representation on paper, just as the programmer sees it.   In a conventional program, which clauses are linked to which statements is represented in two different ways:

1. Indentation, for the benefit of the human.
2. Statement...end pair of tokens for the parser.

Given that Tabetha is designed for the benefit of the human, the Tabetha 1 parser solely uses the method designed for the benefit of the human.   It uses the indentation of each line to establish which clauses belong to which statements.   As a result:

1. The 'end' clause becomes redundant.   Since end clauses consume a significant proportion of source vertical space, this helps Tabetha programs to be more concise, increasing the number of complete sections of code that can be visible in a single window (and hence avoiding bugs where two inconsistent statements are never displayed in the same window). 
2. A programmer using a conventional language can lead himself astray by using correct indentation, but incorrect ends (and elses).  This possibility for error is removed in Tabetha; if the nesting looks right, it is right!   Hence Tabetha programs will have fewer bugs than conventional programs.
 

Python is probably the best-known language that uses indention to indicate grouping.  This works quite well, but unfortunately it requires that all programmers use the same indention style -- hence alientating many programmers, and forcing all programmers to do the parsing for the compiler/interpreter.   Further, it does not allow 'naming' of the ends of loops and other constructs in the way the NetRexx (and partially, Rexx and BASIC) do.   I find it extremely helpful, in complex code, to have a name on an end (or leave or iterate) that matches the label or name at the top of the construct.

 

I do agree with the advantage of reducing vertical space.   I suppose it could be a switch, such as:  Options NoEnds

 
This same idea could be adopted by a new version of NetRexx.   

Tabetha 2 went on to a better method still, but a bigger leap from today's NetRexx. 

If this is not just an academic exercise, why not implement Tabetha 2, calling it NetRexx 3?   They are ideologically similar, and indeed, if Tabetha 2 were to be implemented, the easiest way to do it would be to produce a translator to turn Tabetha programs into NetRexx!   NB, Tabetha 2 requires a more sophisticated editor than those used for conventional programming languages.    

 

Requiring that one has to use a special editor in order to use a given language certainly opens up possibilities (remember "syntax-driven" editors?) -- but it is a sure-fire way to doom a language to obscurity.  Programmers are more 'religious' about the editors they use than they are about the languages they use.   Many program in multiple languages; few use more than one editor.

 

Mike  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Jeff Hennick]

On 8/27/2010 9:43 AM, Mike Cowlishaw wrote:

Python is probably the best-known language that uses indention to indicate grouping.  This works quite well, but unfortunately it requires that all programmers use the same indention style -- hence alientating many programmers, and forcing all programmers to do the parsing for the compiler/interpreter.   Further, it does not allow 'naming' of the ends of loops and other constructs in the way the NetRexx (and partially, Rexx and BASIC) do.   I find it extremely helpful, in complex code, to have a name on an end (or leave or iterate) that matches the label or name at the top of the construct.

I have a lot more experience with Rexx than with Python.  But when using Python, I have problems with "copy and paste" editing whether from my own, or from "example code (that might use 1, 2, 3, or ? spaces or tabs per level," to get the indentations right.  And if a piece of code is more than one screen full, which level am I looking at as I page up and down?  [This may be an example of Mike's next point, too.]

...   

 

Requiring that one has to use a special editor in order to use a given language certainly opens up possibilities (remember "syntax-driven" editors?) -- but it is a sure-fire way to doom a language to obscurity.  Programmers are more 'religious' about the editors they use than they are about the languages they use.   Many program in multiple languages; few use more than one editor.

Yay XEdit/KEdit! :-)

 
Jeff Hennick

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[FreeFall]

On 27 Aug 2010, at 15:11, Jeff Hennick wrote:

On 8/27/2010 9:43 AM, Mike Cowlishaw wrote:

Python is probably the best-known language that uses indention to indicate grouping.  This works quite well, but unfortunately it requires that all programmers use the same indention style -- hence alientating many programmers, and forcing all programmers to do the parsing for the compiler/interpreter.   Further, it does not allow 'naming' of the ends of loops and other constructs in the way the NetRexx (and partially, Rexx and BASIC) do.   I find it extremely helpful, in complex code, to have a name on an end (or leave or iterate) that matches the label or name at the top of the construct.

I have a lot more experience with Rexx than with Python.  But when using Python, I have problems with "copy and paste" editing whether from my own, or from "example code (that might use 1, 2, 3, or ? spaces or tabs per level," to get the indentations right.  And if a piece of code is more than one screen full, which level am I looking at as I page up and down?  [This may be an example of Mike's next point, too.]

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation.   There is no advantage to be gained from inconsistent nesting, so best to prevent it.   This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this.   The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference...

If a piece of code is too big to fit one screen/window, it is generally a good idea to break it down into more manageable pieces. 

...   

 

Requiring that one has to use a special editor in order to use a given language certainly opens up possibilities (remember "syntax-driven" editors?) -- but it is a sure-fire way to doom a language to obscurity.  Programmers are more 'religious' about the editors they use than they are about the languages they use.   Many program in multiple languages; few use more than one editor.

Yay XEdit/KEdit! :-)

 
Jeff Hennick

Good point.   It depends on whether the advantages of using a language based on Tabetha 2 outweigh the preference for one's existing editor (I think that the advantage of Tabetha 2 is enormous).    Having said that, no doubt existing editors could be modified with plugins to provide the required functionality.  

Tabetha 1, however, does not need a special editor, though ideally the editor should be able to support automatically consistent nesting.

Connor.

    

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation.   There is no advantage to be gained from inconsistent nesting, so best to prevent it.   This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this.   The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference... 

 

Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used).   If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor.  When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.   

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Mike,
No opinion on assertions.  But is NetRexx only for "scripts" which I think means an implicit class with only one implicit main method?  Isn't it also for writing full scale oo classes?  I see scripts as a useful bit of icing on the cake.
George

On Fri, Aug 27, 2010 at 9:27 AM, Measel, Mike <[hidden email]> wrote:

Not needed.  If you want assertions then in the nrx code use assertions as comments and use the –java option with nrc.  Quick replace of “— assert” and recompile with javac.

 

Question – who would want assertions in their scripts ?   Pedantic.

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Thomas Schneider
Sent: Friday, August 27, 2010 7:41 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Assertions -- was Proposed NetRexx Languageimprovements

 

Ok, then which syntax for assertions would you propose ?

I originally did use
    x=13+14 ::<=27

But this would meen that the current NetRexx Compiler cannot be used, thus I thought
'enhancing' the note (by using --:) to denote assertions and introduce option assert
would be a viable solution.

Thomas.



Am 27.08.2010 13:58, schrieb Marc Remes:

Any 'improvement' should maintain backwards compatibility.

>>3.) The Note (line comment) delimiter should be re-specified as beeing  '(blank)--(blank)'
will break existing programs

>>4.) Assertions: x=13+14 --:<=27
may break existing programs

Best regards

Marc Remes

IBM Certified IT Specialist
IBM Global Technology Services
Mobile: [phone]
[hidden email]



Tenzij hierboven anders aangegeven: / Sauf indication contraire ci-dessus: / Unless otherwise stated above:

International Business Machines of Belgium sprl / bvba
Siège social / Maatschappelijke zetel: Avenue du Bourget 42 Bourgetlaan, B-1130 Bruxelles/Brussel
N° d'entreprise / Ondernemingsnr: TVA / BTW BE 0405 912 336
RPM Bruxelles / RPR Brussel

_______________________________________________

Ibm-netrexx mailing list

[hidden email]

 

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Aviatrexx]

Not to mention that one of the more frustrating aspects of the new
smartphones is that they don't seem to know about tabs in the first place.

Yeah, I know, no one is going to be doing a lot of production
programming on a handheld, but I did a small amount of Rexx
programming on my Palm and all its successors until the Droid replaced
my Centro smartphone (for telephony reasons).

Mostly they were applets and demos, but it was useful to have that
capability.  I was hoping to use NetRexx on the Droid but I gather
that it has a "Java-ish" VM and is not (for legal reasons) true Java.

-Chip-

On 8/27/10 15:37 Mike Cowlishaw said:

> This problem is not due to using indentation to indicate nesting, it is
> due to inconsistent indentation.   There is no advantage to be gained
> from inconsistent nesting, so best to prevent it.   This problem is
> solved by using any editor which uses one tab for each indentation
> level, and automatically replacing any spaces that the programmer may
> use for the same purpose (I guess that most editors should be capable of
> supporting this.   The quantity of horizontal space that the tab
> represents can be adjusted to fit programmer preference...
>  
> Tabs are a no-go for those of us who do use more than one editor,
> because it seems quite arbitrary how many spaces each tab represents (I
> have seen 2, 4, 5, and 8 all commonly used).   If tabs are not mixed
> with spaces it sort of works .. but line comments over the the right all
> end up misaligned when one changes from editor to editor.  When tabs and
> spaces for indentation are mixed, or sometimes spaces are used and then
> on other lines tabs are used, then one just ends up with a mess for the
> initial indention, too.  
>  
> Mike
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[alansam]

On 27 August 2010 10:55, George Hovey <[hidden email]> wrote:

Mike,
No opinion on assertions.  But is NetRexx only for "scripts" which I think means an implicit class with only one implicit main method?  Isn't it also for writing full scale oo classes?  I see scripts as a useful bit of icing on the cake.
George

If we're into full scale [Java] oo classes then testing with JUnit is way more valuable than assertions.

Alan.
--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

Chip,

fortunately, Kermit Kiser has given us http://kermitkiser.com/AndRexx/Android%20NetRexx%20IDE%20prototype.html

best regards,

René.

On 27 aug 2010, at 19:57, Chip Davis wrote:

> Not to mention that one of the more frustrating aspects of the new smartphones is that they don't seem to know about tabs in the first place.
>
> Yeah, I know, no one is going to be doing a lot of production programming on a handheld, but I did a small amount of Rexx programming on my Palm and all its successors until the Droid replaced my Centro smartphone (for telephony reasons).
>
> Mostly they were applets and demos, but it was useful to have that capability.  I was hoping to use NetRexx on the Droid but I gather that it has a "Java-ish" VM and is not (for legal reasons) true Java.
>
> -Chip-
>
> On 8/27/10 15:37 Mike Cowlishaw said:
>> This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation.   There is no advantage to be gained from inconsistent nesting, so best to prevent it.   This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this.   The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference...  Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used).   If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor.  When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.    Mike ------------------------------------------------------------------------
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Mike,
My two cents on tabs.

Tabs are a holdover from the days when we entered programs on 110 baud Teletypes and would have considered using strings of spaces an obscene waste of computer resources.  They are huge trouble makers for the reasons you have described and (IMHO) should have been discontinued ages ago.

jEdit handles this quite nicely by defining "soft" tabs which cause the TAB key to emit spaces in numbers equivalent to traditional hard tabs.  Of course, other editors may not support this idea, or the programmer may destroy consistent tabbing through incautious editing.  So the burden of checking indentation should be on the compiler.

One approach is to specify an  equivalent tab size with an option (default value 8 for 'nix users?); leading strings of spaces not containing an integer multiple of this value could be flagged by the compiler as an aid to programmers.  It could also make other checks, such as verifying that increasing levels of indentation differ by exactly one tab equivalent.  It might even, as a convenience, optionally fix programs containing hard tabs and re-tab programs to a different value on demand for use with different editors.

Wouldn't this approach make the concept of indentation indicating conditionality safe and convenient?  It seems to me that Connor's idea of regarding a program as a visual artifact plays to one of the mind's great strengths.  And the value of consistent indentation has been understood heuristically for decades (I started with FORTRAN IV); what is gained by not making it a requirement of NetRexx?
George

On Fri, Aug 27, 2010 at 11:37 AM, Mike Cowlishaw <[hidden email]> wrote:

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation.   There is no advantage to be gained from inconsistent nesting, so best to prevent it.   This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this.   The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference... 

 

Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used).   If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor.  When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.   

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Connor,

Netrexx3 <- Tabetha2 seems to me a non starter, for the simple reason that you have not an iota of field experience with Tabetha.

Experience shows that languages always have unintended consequences.  For example, Java was designed by a team of conspicuously smart people and ideas extensively bounced around.  Still, Java's OO model turned out to have consequences that its designers didn't like one bit (see Joshua Bloch, "Effective Java" for various examples).

MFC has always been extremely suspicious of "innovations" in NetRexx, and I think his suspicions well founded.  Novelties should only be introduced cautiously.  The last thing NetRexx needs IMHO is to fall victim to "feature-itis".  In fact,  I could be happy with it as it is, except for fears about future Java compatibility those in the know say are unfounded.

But that doesn't mean there are no new ideas worthy of inclusion in NetRexx, and I hope you will continue to expound on features of Tabetha and their virtues.  What I've heard so far seems well worth pondering.  Does Tabetha have a "white paper"?  BTW, does your use of indentation as a language element pre-date Python's?

On Fri, Aug 27, 2010 at 7:37 AM, Connor Birch <[hidden email]> wrote:

Is this an academic exercise, or is there a real prospect of creating a definition of new version of NetRexx, and a likelihood of it being implemented?   

On the question of end clauses, I could recommend the solution used in Tabetha 1.  A Tabetha program is not considered by the parser to be a single long string, but a two dimensional representation on paper, just as the programmer sees it.   In a conventional program, which clauses are linked to which statements is represented in two different ways:

1. Indentation, for the benefit of the human.
2. Statement...end pair of tokens for the parser.

Given that Tabetha is designed for the benefit of the human, the Tabetha 1 parser solely uses the method designed for the benefit of the human.   It uses the indentation of each line to establish which clauses belong to which statements.   As a result:

1. The 'end' clause becomes redundant.   Since end clauses consume a significant proportion of source vertical space, this helps Tabetha programs to be more concise, increasing the number of complete sections of code that can be visible in a single window (and hence avoiding bugs where two inconsistent statements are never displayed in the same window). 
2. A programmer using a conventional language can lead himself astray by using correct indentation, but incorrect ends (and elses).  This possibility for error is removed in Tabetha; if the nesting looks right, it is right!   Hence Tabetha programs will have fewer bugs than conventional programs.

This same idea could be adopted by a new version of NetRexx.   

Tabetha 2 went on to a better method still, but a bigger leap from today's NetRexx. 

If this is not just an academic exercise, why not implement Tabetha 2, calling it NetRexx 3?   They are ideologically similar, and indeed, if Tabetha 2 were to be implemented, the easiest way to do it would be to produce a translator to turn Tabetha programs into NetRexx!   NB, Tabetha 2 requires a more sophisticated editor than those used for conventional programming languages.   

Connor.

On 26 Aug 2010, at 07:57, Mike Cowlishaw wrote:

1.) Syntax and semantics of the end statement.

   The 'end' clause should allow an optionional argument to 

say 'what do I end' , e.g.

   select case a

      when 'abc' then ...

      when 'def' then ...

      otherwise ...

   end select ...

    This would make the usage of Notes (line comments) at 

the end unnecessary.

This is already there -- the syntax is:

    select label chooser case a

       when 'abc' then ...

       when 'def' then ...

       otherwise ...

    end chooser

Mike

_______________________________________________

Ibm-netrexx mailing list

[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Kermit Kiser]

Actually the jEdit developers are at this moment in the process of implementing something called "elastic tabstops" which appears to be far superior to tabs and spaces as it can automatically align things even if the programmer does not use the correct tabs or spaces. However I would be worried about making NetRexx require indentation (thinking of Cobol, etc. ugh!) as it could conflict with slick new tools like elastic tabstops.

http://en.wikipedia.org/wiki/Elastic_tabstop

-- Kermit


On 8/27/2010 1:12 PM, George Hovey wrote:

Mike,
My two cents on tabs.

Tabs are a holdover from the days when we entered programs on 110 baud Teletypes and would have considered using strings of spaces an obscene waste of computer resources.  They are huge trouble makers for the reasons you have described and (IMHO) should have been discontinued ages ago.

jEdit handles this quite nicely by defining "soft" tabs which cause the TAB key to emit spaces in numbers equivalent to traditional hard tabs.  Of course, other editors may not support this idea, or the programmer may destroy consistent tabbing through incautious editing.  So the burden of checking indentation should be on the compiler.

One approach is to specify an  equivalent tab size with an option (default value 8 for 'nix users?); leading strings of spaces not containing an integer multiple of this value could be flagged by the compiler as an aid to programmers.  It could also make other checks, such as verifying that increasing levels of indentation differ by exactly one tab equivalent.  It might even, as a convenience, optionally fix programs containing hard tabs and re-tab programs to a different value on demand for use with different editors.

Wouldn't this approach make the concept of indentation indicating conditionality safe and convenient?  It seems to me that Connor's idea of regarding a program as a visual artifact plays to one of the mind's great strengths.  And the value of consistent indentation has been understood heuristically for decades (I started with FORTRAN IV); what is gained by not making it a requirement of NetRexx?
George

On Fri, Aug 27, 2010 at 11:37 AM, Mike Cowlishaw <[hidden email]> wrote:

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation.   There is no advantage to be gained from inconsistent nesting, so best to prevent it.   This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this.   The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference... 

 

Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used).   If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor.  When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.   

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

  Hello Chip,
     contact Kermit Kiser ([hidden email]).

He already DID a nice Android App written totally in NetRexx!

He also has sample code/doc what to do to program in NetRexx on an
Android handy.
Thomas.
===========================================================
Am 27.08.2010 19:57, schrieb Chip Davis:

> Not to mention that one of the more frustrating aspects of the new
> smartphones is that they don't seem to know about tabs in the first
> place.
>
> Yeah, I know, no one is going to be doing a lot of production
> programming on a handheld, but I did a small amount of Rexx
> programming on my Palm and all its successors until the Droid replaced
> my Centro smartphone (for telephony reasons).
>
> Mostly they were applets and demos, but it was useful to have that
> capability.  I was hoping to use NetRexx on the Droid but I gather
> that it has a "Java-ish" VM and is not (for legal reasons) true Java.
>
> -Chip-
>
> On 8/27/10 15:37 Mike Cowlishaw said:
>> This problem is not due to using indentation to indicate nesting, it
>> is due to inconsistent indentation.   There is no advantage to be
>> gained from inconsistent nesting, so best to prevent it.   This
>> problem is solved by using any editor which uses one tab for each
>> indentation level, and automatically replacing any spaces that the
>> programmer may use for the same purpose (I guess that most editors
>> should be capable of supporting this.   The quantity of horizontal
>> space that the tab represents can be adjusted to fit programmer
>> preference...
>> Tabs are a no-go for those of us who do use more than one editor,
>> because it seems quite arbitrary how many spaces each tab represents
>> (I have seen 2, 4, 5, and 8 all commonly used).   If tabs are not
>> mixed with spaces it sort of works .. but line comments over the the
>> right all end up misaligned when one changes from editor to editor.  
>> When tabs and spaces for indentation are mixed, or sometimes spaces
>> are used and then on other lines tabs are used, then one just ends up
>> with a mess for the initial indention, too.
>> Mike
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
_______________________________________________
Ibm-netrexx mailing list
[hidden email]