Fwd: The current state of *MY SOFT* ;-)

[ThSITC]

As many of the issues raised below might need a thorough discussion ...
I am now forwarding this mail and the ancient prior mails to this discussion list.

Please do *read* the and *then* reply, bu usinghte *proper* *topic*
as the header (topic) of Your reply ... ;-)

Thomas Schneider.
=====================================================================

-------- Weitergeleitete Nachricht --------

Betreff:	The current state of *MY SOFT* ;-)
Datum:	Wed, 2 Dec 2015 23:30:14 +0100
Von:	Thomas Schneider [hidden email]
An:	René Jansen [hidden email], Kermit Kiser [hidden email]

Hi there,

as You know, I'm working on a *potential* alternative to the current 
NetRexx Compiler.

As a *simple reminder*, I'm forwarding You The *propositions* I did 
raise long time ago  .... ;-)

Thomas.

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

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 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 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
------------------------------------------------------------------
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 (o 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.

I

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

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

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