My ancient NetRexx improvements ...

[ThSITC]

Hello there,

by cleaning up my own ancient Windows 10 Computer (3 Years old, hence
ancient) ...

... I did find an ancient document of mine I would like to RE-PUBLISH again:

##################################################################

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

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 RexxMsg, RexxFile

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

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

*BUT*

          ic1 = 18

*does NOT have the desired effet, to set the *used* property of RexxMsg 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-5 under
this thread,
as I would like to raise *this discussion here*
(as not been advised to raise it elsewhere)

Thomas Schneider.

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

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
------------------------------------------------------------------
3.) The Note (line comment) delimiter should be re-specified as beeing
'(blank)--(blank)'

      reasons:

This would allow for the usage of the Java postfix operatores ++
(Increment),
and -- (decrement), and also would allow for my proprosed *assertion Syntax*

4.) Assertions:

One of the most desirable thing for a programmer is to assert that his
program
will run:

I am proposing the followind Syntax

       c=14
       b=13
       x=13+14 --:<=27

i.e.

      the '--:' operator introduces an ASSERTION.

In ordinary NetRexx (vs.2) it will be considered as a Line Comment
(or Note, as I call it)

In ReyC, my upcoming Rey Compiler, it will be considered as an assertion

5.) a new option  -assert, should be introduced:

This will allo the NetRexx/Rey Compiler to Generate Assertions (using JUnit)

I have changed my mind to this now newly proposed syntax, so that the
presence of
ASSERTIONS does NOT influence the desired source code compatibility to
current NetRexx

6.) Enumerations:

Enumerations should be implemented as quick as possible:

Proposed Syntax:

       a=Rexx {'ABC','DEF','GEF'}

The FIRST entry should denote the default value for this specific Variable.

I'm also proposing that the quotes may be omitted (only within the
Braces), e.g.

       answer={YES,NO}

Tom.


--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
---------------------------------------------------------------------------------------
  7.) As I did work for General Electric Information Services (GEISCO),
which did provide
something like the *Internet* decades decades ago (I did startthe 1964,
I think)
but lost the game as they have been too stupid to quickly react:

I'm also proposing a syntax for VALUE-Lists:

7.1) a Value List is either a simple value list (also called
Enumeration), or a Value RANGE list.
7.2) A Value List becomes a value-range-list if (and only if) any memebt
of the list is a range
7.3) Within the value list, *NO variables* are allowed
7.4) Values may be entered unquoted, unless a delimiter is used.
7.5.) When a delimiter is used, it must be quoted
7.6) I am proposing the COLON (:) as the commonly used range indicator.

thus, the following would be proprose NetRexx 3 syntax:

     i =int i {3,5,7,9,11,12:13,17}
detto:

    answer={YES,NO}

Quotes may be omitted within the braces, when not necessary, because
delimiters are used.

The two examples above will form (simple) value lists

8.) Value-range-lists:

     a typical value Range list will be:

        a={1,3,7:9,12,13:44}

     We must still decide whether we should allow the HYPHEN (instead of
the COLON)
as the range separator (or both the hyphen for numerics and the colon
generally)

Comments are welcome :-)

9) Usage of value lists or value range-lists

      typical usages might be

          a=ask
          if a \= {YES,NO} then error('invalid answer')

Comments are welcome!
Tom.



####################################################################

Kindly, Thomas Schneider, Vienna, Austria.



---
This email has been checked for viruses by AVG.
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avg.com&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_6rXNpPJ1fYV-3bV1za02NiR4PUelvicfHXwtnTXpXE&m=lDEFiTHkg67PQrsvmlpqSqjWVIEguE42017EFOuH0RE&s=LWMiMElQp3vtYMNswY3vx3Wv59Ru5FKKFEOFa6OLT0I&e=


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