NetRexx system environment variables

[David Requena]

2010/11/16 Bill Fenlason <[hidden email]>

.The problem I was addressing earlier is one of the finer points related to the need to search all the included classes rather than the fundamental problem of keyword and variable name clashes.

If a keyword name is a method name in an included class, it is theoretically possible for the keyword to be overloaded.  That means if a source processing program is to precisely mirror the operation of the NetRexx translator, it must also process dynamically (i.e. examine data not within the NetRexx source) in some situations.  Unfortunately the example shown on page 77 did not include "say ;".  Our interpretation is that it could either be a "say" keyword statement or an included method call in some cases.

Bill,

While I mostly agree with your remarks, this particular one got me intrigued.

Any appearance of an externally defined method or field would be prefixed by an instance or class reference, hence allowing for "context keyword recognition". That still requires further examination of that class in order to determine if a given token not followed by a set of parentheses is a method or a field but just that class, not all-included/classes as you state.

The other scenario I can think of is the presence of a "uses" modifier keyword at the class being processed. That allows for unprefixed calls to methods and field references. Again that requires further examination of a well defined set of classes: the used one and its ancestors.

The current language processor certainly scans all available classes to the default class loader on launch but I'd say this is a totally independent subject related to how the compiler *and* interpreter load classes afterward. They never get back to use the standard class loader chain.

Am I missing something evident?

--
Saludos / Regards,
David Requena


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

May I, (usig the same thread), as an example forward you the ouput
of the current SCAN Pass of a couple of NetRexx programs of mine.

I do distinguish between Verbs (followed by a blank) and the 'other
keywords', which are context sensitive.

Thus, SAY, as a verb, remains a Verb.

A Verb is the first token of a 'instruction', as defined by MFC.

To do the Job of 'rough Program analysis', you might therefor use:

ReyC -SCAN *.nrx      --- scans all NetRexx programs, giving the
                                            Program Metrics, by default

ReyC -SCAN *.rex      -- scans all classic Rexx and/or ooRexx Programs

etc, etc

The example output follows.
Thomas Schneider.
========================================================
ReyC version: 0.2

Processing file: K:\com\thsitc\rey\rt\ClassDef.nrx
==================================================


Program Metrics: Program: K:\com\thsitc\rey\rt\ClassDef.nrx
===========================================================


Verb                 Count
----                 -----
CLASS                    1
DO                      33
ELSE                     2
END                     40
IF                      20
ITERATE                  3
LOOP                     5
METHOD                  10
OTHERWISE                2
PACKAGE                  1
PARSE                    4
PROPERTIES               2
RETURN                  18
SELECT                   2
WHEN                     8



Code Statistics:
================

         no Block Comments
         25 Documentation lines
         no Blank lines
        247 Source lines
         44 Notes (line Comments)

         no Errors
         no Warnings
         no Fatal Errors

Scanning File: K:\com\thsitc\rey\rt\ClassDef.nrx used: 0.125 seconds
Memory usage was: 1 MB

Processing file: K:\com\thsitc\rey\rt\External.nrx
==================================================


Program Metrics: Program: K:\com\thsitc\rey\rt\External.nrx
===========================================================


Verb                 Count
----                 -----
CATCH                    6
CLASS                    1
DO                      51
ELSE                    17
END                     88
IF                     103
IMPORT                   2
ITERATE                  8
LEAVE                    4
LOOP                    33
METHOD                  37
NOP                      1
OTHERWISE                4
PACKAGE                  1
PARSE                    3
PROPERTIES               4
RETURN                  61
SAY                      7
SELECT                   4
WHEN                    17



Code Statistics:
================

         no Block Comments
        102 Documentation lines
         no Blank lines
       1054 Source lines
         60 Notes (line Comments)

         no Errors
         no Warnings
         no Fatal Errors

Scanning File: K:\com\thsitc\rey\rt\External.nrx used: 0.203 seconds
Memory usage was: 2 MB

Processing file: K:\com\thsitc\rey\rt\Global.nrx
================================================


Program Metrics: Program: K:\com\thsitc\rey\rt\Global.nrx
=========================================================


Verb                 Count
----                 -----
CLASS                    1
DO                      22
END                     24
IF                      33
ITERATE                  3
LOOP                     2
METHOD                  10
PACKAGE                  1
PARSE                    2
PROPERTIES               3
RETURN                  11



Code Statistics:
================

         no Block Comments
         84 Documentation lines
         no Blank lines
        530 Source lines
        106 Notes (line Comments)

         no Errors
         no Warnings
         no Fatal Errors

Scanning File: K:\com\thsitc\rey\rt\Global.nrx used: 0.094 seconds
Memory usage was: 1 MB

Processing file: K:\com\thsitc\rey\rt\Options.nrx
=================================================


Program Metrics: Program: K:\com\thsitc\rey\rt\Options.nrx
==========================================================


Verb                 Count
----                 -----
CLASS                    1
DO                     127
ELSE                     3
END                    129
IF                      14
LOOP                     1
METHOD                   4
OPTIONS                  1
OTHERWISE                1
PACKAGE                  1
PARSE                    1
PROPERTIES               1
RETURN                   4
SELECT                   1
WHEN                   121



Code Statistics:
================

         no Block Comments
         50 Documentation lines
         no Blank lines
        636 Source lines
        149 Notes (line Comments)

         no Errors
         no Warnings
         no Fatal Errors

Scanning File: K:\com\thsitc\rey\rt\Options.nrx used: 0.094 seconds
Memory usage was: 1 MB

Processing file: K:\com\thsitc\rey\rt\ReyAssert.nrx
===================================================


Program Metrics: Program: K:\com\thsitc\rey\rt\ReyAssert.nrx
============================================================


Verb                 Count
----                 -----
CLASS                    1
DO                       1
END                      2
IF                       3
METHOD                   3
OTHERWISE                1
PACKAGE                  1
RETURN                   5
SELECT                   1
WHEN                     9



Code Statistics:
================

         no Block Comments
          8 Documentation lines
         no Blank lines
         50 Source lines
          1 Notes (line Comments)

         no Errors
         no Warnings
         no Fatal Errors

Scanning File: K:\com\thsitc\rey\rt\ReyAssert.nrx used: 0.031 seconds
Memory usage was: 1 MB

Processing file: K:\com\thsitc\rey\rt\ReyBits.nrx
=================================================


Program Metrics: Program: K:\com\thsitc\rey\rt\ReyBits.nrx
==========================================================


Verb                 Count
----                 -----
CLASS                    1
END                      1
IF                       1
LOOP                     1
METHOD                   8
OPTIONS                  1
PACKAGE                  1
RETURN                   8



Code Statistics:
================

         no Block Comments
         13 Documentation lines
         no Blank lines
         41 Source lines
         no Notes (line Comments)

         no Errors
         no Warnings
         no Fatal Errors

Scanning File: K:\com\thsitc\rey\rt\ReyBits.nrx used: 0. seconds
Memory usage was: 1 MB

Processing file: K:\com\thsitc\rey\rt\ReyCond.nrx
=================================================


Program Metrics: Program: K:\com\thsitc\rey\rt\ReyCond.nrx
==========================================================


Verb                 Count
----                 -----
CLASS                    1
DO                       5
END                      6
IMPORT                   1
METHOD                   1
OTHERWISE                1
PACKAGE                  1
PROPERTIES               1
RETURN                   1
SAY                      1
SELECT                   1
WHEN                     4



Code Statistics:
================

         no Block Comments
          6 Documentation lines
         no Blank lines
         36 Source lines
          2 Notes (line Comments)

         no Errors
         no Warnings
         no Fatal Errors

Scanning File: K:\com\thsitc\rey\rt\ReyCond.nrx used: 0.015 seconds
Memory usage was: 1 MB

Processing file: K:\com\thsitc\rey\rt\ReyErr.nrx
================================================


Program Metrics: Program: K:\com\thsitc\rey\rt\ReyErr.nrx
=========================================================


Verb                 Count
----                 -----
CLASS                    1
METHOD                   1
OPTIONS                  1
PACKAGE                  1
PROPERTIES               1
RETURN                   1



Code Statistics:
================

         no Block Comments
          3 Documentation lines
         no Blank lines
         12 Source lines
          1 Notes (line Comments)

         no Errors
         no Warnings
         no Fatal Errors

Scanning File: K:\com\thsitc\rey\rt\ReyErr.nrx used: 0.015 seconds
Memory usage was: 1 MB


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

2010/11/16 Chip Davis <[hidden email]>

The fact that NetRexx confounds antlr, yacc, javacc, et ilk is a plus in my book.

-Chip-

That one is a truly amazing statement Chip.

I could understand that not having a simple correct NetRexx syntax highlighting editor in existence just because of the fact above might be 'indifferent' or 'a minus' in someone's book but... a plus?!! 

Are we really wishing a successful language with a broad audience?

I could have a fairly complete Netbeans integration within a week if an antlr grammar for NetRexx was indeed feasible, which I frankly doubt by now.

As things are, my only prospect is to yank the (open sourced) NetRexx compiler innards into a Netbeans module and plunge into a nightmarish ordeal of gluing it to the platform low level APIs. I guess it just might not happen soon...

--
Saludos / Regards,
David Requena


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Relating my previous mail:

Oh, I forgot to say:

1.) The EOS (end of statement character) may of course also follow a Verb!
2.) If the first token is followed by one of the supported ASSIGN
delimiters (=,
+=, -=, etc)  *or* a comma, then an ASSIGNMENT is assumed, and the first
Token becomes a Variable (or Stem).
3.) If the first token is immediately followed by an open Parenthesis,
then it MUST be a method invokation (in NetRexx).

Tom.


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Kermit Kiser]

I don't see the problem here. If I wanted to use a new keyword "xyz" in an old program it would only take one "change all" editor command to turn any "xyz" variables into "xyzold" variables before adding the new "xyz" keyword reference. Granted if I did not write the original program, I might not know that "xyz" was used as a variable but that is easy to check for. If "xyz" had been used as a public method name, that is another ball game as there might be other source programs that needed to change also but that does not seem like a common problem.

As for the language parsing problem, I recall taking a stab at coding a NetRexx parser once years ago - the main problem I encountered was in handling block comments. This is not because they can contain any valid or invalid code sequences, but because, in contrast to Java, they can be nested and be inserted practically anywhere possibly causing automatic line continuation as in Java. Mike does give a limit of 10 nesting levels as a practical guideline, so I suppose it can still be handled by a "finite" state analyzer but it does complicate the parser a bit.

-- Kermit


On 11/16/2010 1:02 PM, George Hovey wrote:

>The trade off is that the old program cannot use the new "xyz" statement until it is changed so that "xyz" is no longer a variable or method name.

Exactly the case I had in mind.  This could conceivably cause serious pain, and there is no justification for calling it improbable since the probability is unknowable.  Can we say that it is unimportant to head off this possibility, especially if it can be totally prevented?  [I have no idea how, or whether the cost of doing so would be acceptable.]

As I've noted before, at least one language (FORTRAN) has no reserved words and can recognize a keyword followed by a variable with or without an intervening space.  Has the secret of this technology died with Backus?

I take it you see no need to adjust NetRexx's ideas on concatenation, which I'm glad to hear, as it would break ALL of my programs  :) !

On Tue, Nov 16, 2010 at 2:34 PM, Bill Fenlason <[hidden email]> wrote:

On 11/16/2010 11:20 AM, George Hovey wrote:

Bill,
I've been following your remarks on keywords, etc with great interest.  Here are a couple of things I've wondered about.

• I have a nagging doubt about the claim that NetRexx's current approach to new keywords won't break old programs.  Perhaps I misunderstand but it seems to me that it could hamper the user's ability to maintain a program, and this might have serious consequences in, say, managing a big project subject to continual fixes and updates.  Since we can't predict how a user might run afoul of a keyword conflict (eg, how extensively it might affect his code), he could conceivably be placed in a considerable bind if a NetRexx change came at a delicate stage of some program modification.  Or is this argument defective?  Even if so, it still sounds desirable (in principle) to definitively remove keywords as an issue, as you describe.  Specifically, what would have to change?  Could old and new ways coexist?
  

Suppose NetRexx adds an "xyz" statement, and an old program has a variable or method named "xyz".  When the NetRexx interpreter processes the old program, "xyz" will not be recognized as a keyword, even though the new interpreter can process "xyz" statements.  The trade off is that the old program cannot use the new "xyz" statement until it is changed so that "xyz" is no longer a variable or method name.  That is how NetRexx successfully remains keyword independent.  If programs are being modified after the "xyz" statement is added, users will have the opportunity to make the changes at that point (if necessary).  But old unmodified programs will always work.

• You mention that the "blank concatenate operator" is a sticking point in language processing.  Does this also apply to concatenation by abutment?   How would you propose to handle concatenation?
  

I've always felt that the invention of the blank (and abutment) operators was brilliant.

The problem I referred to is that (in essence) an expression consists of a variable followed by any number of operator, variable pairs.  It gets more complicated than that, but when all is said and done the end of an expression (in other languages) can be recognized because two consecutive variables are not allowed.  A following word can be known to be a keyword (by context).  Because of the blank concatenate operator, a word following a variable in an expression can either be a keyword or another variable.  In Rexx any keyword following an expression is reserved, but in NetRexx variables are given priority over keywords.  For example, the sequence:  to = 'abc';  loop i = 1 to 3; will likely fail because it is equivalent to loop i = 1 || " " || 'abc' || " " || 3;

As Mike mentioned in an earlier append, there are various ways to design the concatenate operator.

Bill

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

Well, I was at the JVM language conference a few years ago, and the Antlr people were discussing 'how language designers should make things easier and more regular for grammar writers.' (my paraphrase). The focus of these statements were Ruby, and it was discussed that 'starting language designers do not know how it is done' - again my words. I regard Ruby as another successful language that cares more for the user than the parser (but still not my favourite). I agree with Mike and Chip that ease of parsing is not the first concern for the language user - it is an issue for the language toolsmith. I have had enough programs and such (ISPF panels!) broken by 'better' compiler releases to really value the NetRexx (PL/1) approach. When we have the NetRexx source in the open, we should make it easier for the parser to be dropped in tools. For the rest - it might be time for better parser generators. I offered the maker of Antler and some of his friends $1000 for a working NetRexx parser, and although the Antlr book mentions non-keyword based grammars, it did not come about.

best regards,

René.

On Tue, Nov 16, 2010 at 10:56 PM, David Requena <[hidden email]> wrote:

2010/11/16 Chip Davis <[hidden email]>

The fact that NetRexx confounds antlr, yacc, javacc, et ilk is a plus in my book.

-Chip-

That one is a truly amazing statement Chip.

I could understand that not having a simple correct NetRexx syntax highlighting editor in existence just because of the fact above might be 'indifferent' or 'a minus' in someone's book but... a plus?!! 

Are we really wishing a successful language with a broad audience?

I could have a fairly complete Netbeans integration within a week if an antlr grammar for NetRexx was indeed feasible, which I frankly doubt by now.

As things are, my only prospect is to yank the (open sourced) NetRexx compiler innards into a Netbeans module and plunge into a nightmarish ordeal of gluing it to the platform low level APIs. I guess it just might not happen soon...

--
Saludos / Regards,
David Requena


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[billfen]

Chip,

On 11/16/2010 1:13 PM, Chip Davis wrote:

Correct me if I'm wrong (which in this group goes without saying) but did not this whole issue arise from a litany of the problems parsing NetRexx source code?

It seems to me that these are not issues of _programming_ in NetRexx or of maintaining a NetRexx application, regardless the size.   They instead reflect the difficulty of trying to externally parse a NetRexx program's source statements, certainly a second-order problem.

While you are certainly entitled to judge the parsing of NetRexx source to be a "second-order" problem, I suggest that it is a significant problem.  I wouldn't classify it as "second rate", but just as a different (and important) kind of problem which should be addressed for the future benefit of the NetRexx language.

Statically parsing the source of any interpreted language is a non-trivial task in the first place.  Mike has unambiguously stated that he sides with the language user over the language processor developer.  Making Rexx/NetRexx behavior easier for the LPD is a rare benefit to an individual at the perpetual expense of all users.

Certainly I agree that the user must come first, and that thoughtless disregard of the user in exchange for implementation expediency is bad.  JCL anyone?  On the other hand, disregarding the genuine needs of the user is not a good idea either, and not all of those needs are related to language syntax.

I don't agree that making NetRexx parsable by generated parsers would be a "perpetual expense of all users".  What about the benefits that users gain by having other programs which can process NetRexx source?  Don't those programs fill user needs?  What do you tell people who express those needs?  "Too bad, use another language"?  What if they say "OK", because they have no other choice?

The fact that NetRexx confounds antlr, yacc, javacc, et ilk is a plus in my book.

I think that thumbing one's nose at any kind of parser technology is unwise.  After all, they are just tools.  As I pointed out earlier, they can be badly used and problematic, just as with any other tool. 

You might consider the fact that essentially all major programming languages (lots of statistics available on the web) have grammars suitable for parser generators.  Would you consider the possibility that a programming language which cannot be easily parsed using a generated parser may become a less popular language with a limited future?  APL anyone?

Are you unaware that Regina Rexx, which undeniably has contributed to significant Rexx usage, uses the Lex / Yacc model?

It's my opinion that in order to accommodate the usage of parser generator technology,  the NetRexx language should move toward the PL/I model in which keywords are unreserved and recognized by context rather than by content and a lower priority with respect to variable names.  I think that probably could be accomplished with a few minor changes which users would not find overly objectionable. 

In other words, there should be an attempt to achieve the best of both worlds with minor compromise. 

-Chip-

Bill

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

René,

I'm not really joining sides on these topics at all.

Still there is a world of difference between "I don't mind breaking antlr, yacc and their kind if I get a better NetRexx" versus "I rejoice having their ilk breaking against our most perfect NetRexx" (both my paraphrases).

Certainly the latter strikes me as quite fundamentalist... Let's hope that mentioned 'pluses and minuses' book is not one of the so-called holy ones ;-)

My preliminary survey of antlr yielded no positive lead at all. I'm by no means an antlr expert but, as previously stated, I pretty much doubt a NetRexx grammar can actually be done for it.  :-(

-
Saludos / Kind regards,
David Requena

-----Original Message-----
From: René Jansen <[hidden email]>
Sender: [hidden email]
Date: Wed, 17 Nov 2010 00:03:15
To: IBM Netrexx<[hidden email]>
Reply-To: IBM Netrexx <[hidden email]>
Subject: Re: [Ibm-netrexx] NetRexx system environment variables

_______________________________________________
Ibm-netrexx mailing list
[hidden email]



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[billfen]

On 11/16/2010 6:03 PM, René Jansen wrote:

Well, I was at the JVM language conference a few years ago, and the Antlr people were discussing 'how language designers should make things easier and more regular for grammar writers.' (my paraphrase). The focus of these statements were Ruby, and it was discussed that 'starting language designers do not know how it is done' - again my words. I regard Ruby as another successful language that cares more for the user than the parser (but still not my favourite). I agree with Mike and Chip that ease of parsing is not the first concern for the language user - it is an issue for the language toolsmith. I have had enough programs and such (ISPF panels!) broken by 'better' compiler releases to really value the NetRexx (PL/1) approach. When we have the NetRexx source in the open, we should make it easier for the parser to be dropped in tools. For the rest - it might be time for better parser generators. I offered the maker of Antler and some of his friends $1000 for a working NetRexx parser, and although the Antlr book mentions non-keyword based grammars, it did not come about.

best regards,

René.

In the above when you said: "... the NetRexx (PL/1) approach...", it implies that both NetRexx and PL/I use the same approach for unreserved keywords.

I would like to point out (yet again) that the NetRexx approach to keyword independence IS NOT the same as the PL/I approach !

NetRexx allows keywords and variable names to clash, and for a keyword to be broken by using it as a variable name.  That can NEVER happen in PL/I because PL/I does not recognize keywords by word content, and NetRexx does. 

In NetRexx, a word is either a keyword or a variable.  Once it is used as a variable, it cannot be used as a keyword again. 

In PL/I a word can be both a keyword and a variable.  When it is a keyword, it is as the language is currently defined.  Keywords are not reserved and old programs can not be broken when new keywords are added.

In PL/I, the sequence:  to = 'abc'; do i = 1 to 3;  the first "to" is a variable name, the second is a keyword.

In NetRexx,  to = 'abc';  loop i = 1 to 3;  does not give the reasonably expected result (looping 3 times) because both occurrences of "to" are variable references and the "to" keyword is broken.  (See NetRexx 2, page 92)

I suggest that NetRexx should be like PL/I in this situation, and not break keywords.  That behavior appears (at least to me) to be in conflict with the "astonishment factor" doctrine.

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

A working NetRexx grammar based parser does exist but it doesn't use Antlr.  The currently available Eclipse NetRexx plugin demonstrates the parser capabilities .

I rejected Antlr because I felt it had too much extraneous stuff.  With JavaCC and JFlex there is no runtime library requirement, and it is much more flexible, simple and "hands on" than Antlr.  I suspect it performs better as well.

I assume the grammar could be readily ported to Antlr, but currently I'm not interested in doing that.  (Even with a $1000 bounty :). 

The current plugin uses a statement / clause level (but full NetRexx language) parser.  The next version will add AST and incremental parsing.  The updates to the grammar include productions for the multi-clause groups and overall program structure, etc. 

The grammar source is currently not part of the plugin.  (But no obfuscation so a decompiler can be used to get a sense of it.)  The full plugin source (including the revised grammar) will be available with the next plugin version and will be released under the Eclipse Public License.  

I don't know how easily David can adapt it or if the Eclipse License is compatible with his work.  Because of the editor environment and the fact that blanks are significant in NetRexx, the grammar includes all the space and comment constructs, etc., and there are a number of specialized methods to handle unique requirements (such as converting keyword tokens to variable name tokens where appropriate, continuation lines, split operators, lookahead, etc.).  My approach to tokens and the scanner are unorthodox.  I suspect there are significant differences between the Eclipse and Netbeans frameworks.

Bill


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Could Chip be dramatizing his distaste for all that is not Rexx?

On Tue, Nov 16, 2010 at 4:56 PM, David Requena <[hidden email]> wrote:

2010/11/16 Chip Davis <[hidden email]>

The fact that NetRexx confounds antlr, yacc, javacc, et ilk is a plus in my book.

-Chip-

That one is a truly amazing statement Chip.

I could understand that not having a simple correct NetRexx syntax highlighting editor in existence just because of the fact above might be 'indifferent' or 'a minus' in someone's book but... a plus?!! 

Are we really wishing a successful language with a broad audience?

I could have a fairly complete Netbeans integration within a week if an antlr grammar for NetRexx was indeed feasible, which I frankly doubt by now.

As things are, my only prospect is to yank the (open sourced) NetRexx compiler innards into a Netbeans module and plunge into a nightmarish ordeal of gluing it to the platform low level APIs. I guess it just might not happen soon...

--
Saludos / Regards,
David Requena


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

Hi Bill,

 

In the above when you said: "... the NetRexx (PL/1) approach...", it implies that both NetRexx and PL/I use the same approach for unreserved keywords.

I would like to point out (yet again) that the NetRexx approach to keyword independence IS NOT the same as the PL/I approach !

I read your first email, and I simply meant the NetRexx (PL/1) approach of not breaking programs, not that they would be the same in that approach. I see advantages in the PL/1 approach, sure - it could very well be breaking them even less. I stated my adhesion to what Chip said in the sense of not minding these grammar parser generator tools very much if they enforce a fixed keyword language - I think the rest of the email made that clear.

If you pull this off, or already haved pulled this off, we might have a full LPEX like colouring in the editors - wow - and while we are at it, a new NetRexx level could well implement this parsing scheme, as long as we can prove that it breaks only broken programs. This, however, would be something that needs to be planned, discussed and decided in the language architecture board. If you can be part of that, drop me a line.

best regards,

René Jansen.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[billfen]

On 11/17/2010 10:56 AM, René Jansen wrote:
> If you pull this off, or already haved pulled this off, we might have
> a full LPEX like colouring in the editors - wow - and while we are at
> it, a new NetRexx level could well implement this parsing scheme, as
> long as we can prove that it breaks only broken programs. This,
> however, would be something that needs to be planned, discussed and
> decided in the language architecture board. If you can be part of
> that, drop me a line.

René ,

Unfortunately, I have not had access to LPEX since 1995 shortly before I
retired.  Back in the late 80's and early 90's I wrote colorizers for
Mike's mainframe LEXX editor which was the precursor editor to LPEX.  As
I recall they were for Rexx, FORTRAN, COBOL, Mainframe Assembler, and
JCL.  Some of them were later converted for the original PC LPEX but I
wasn't involved.  Since then, it is my understanding that LPEX was
rewritten and a commercial version (usable with Eclipse) is available.  
I certainly would like to be able to examine LPEX now to see how it
compares with my work, but currently I have no way of doing that.

So, I don't know what you mean by today's "full LPEX like colouring",
but the Eclipse NetRexx plugin editor already has reasonably
sophisticated coloring.  Every different lexical element can be assigned
it's own font, foreground color and background color.  I don't know why
someone would want some keywords in tiny blue and others in large red
italics, but if so, they can do that.

The plugin editor also shows and colorizes syntax errors while you type,
and I don't know to what extent LPEX has that capability.

I again encourage you to search out an experienced Eclipse user, have
them install the NetRexx plugin and see for yourself.  Frankly, I could
use the feedback.  If all else fails, perhaps I can demonstrate it using
VNC and Skype or an IM with audio (or something like that).

As Chip mentioned earlier, parsing an interpreted language can be
challenging, as is writing a compiler for one.  It was managed for Rexx,
and I think NetRexx (with minor changes) can be accurately processed by
a grammar based parser without having reserved keywords.

Some problems with my NetRexx parser are that the keywords must be
reserved, keyword breakage is not handled and dynamic class searching is
not handled (although David questioned the need for it - perhaps I was
wrong about that and I need to look again in more detail).

I don't think trying to extract the parser from my plugin and using it
in another tool would be easy - there is somewhat more to it than just
dropping a grammar file into Antlr or one of the other tools like DLTK
or XTEXT.

I'll be happy to provide informal suggestions for "NetRexx 3" at an
appropriate time, but I don't presume to be a language designer.  Mike
is the cream of the crop.

Bill






_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

Bill,

2010/11/18 Bill Fenlason <[hidden email]>

Some problems with my NetRexx parser are that the keywords must be reserved, keyword breakage is not handled and dynamic class searching is not handled (although David questioned the need for it - perhaps I was wrong about that and I need to look again in more detail).

My question was about the need to scan "all included cases" as opposed to "some of the included classes". Mind you it was indeed a question as I'm well out of my water when it comes to parsers, lexers and such.

--
Saludos / Regards,
David Requena


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hello David, Bill, and all:

I will present my Parsing algorithms (very shortly) at my speach at the REXXLa 2010 meeting.

As all of those will be OPENED source immediately after this very important meeting (at least for classic Rexx, ooRexx,and NetRexx), I would like that we all *defer* all those minor issues until then ...

Maybe we are discussing something where I already might have a solution for ... :-)

Kind regards from dark Vienna.

Thomas Schneider.
=====================================================
Am 18.11.2010 15:18, schrieb David Requena:

Bill,

2010/11/18 Bill Fenlason <[hidden email]>

Some problems with my NetRexx parser are that the keywords must be reserved, keyword breakage is not handled and dynamic class searching is not handled (although David questioned the need for it - perhaps I was wrong about that and I need to look again in more detail).

My question was about the need to scan "all included cases" as opposed to "some of the included classes". Mind you it was indeed a question as I'm well out of my water when it comes to parsers, lexers and such.

--
Saludos / Regards,
David Requena

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Robert L Hamilton]

In my edition of TNRL, p. 8 are some comments along these lines. One factor to be aware of is the "astonishment factor" and, for me, one such is the lack of  Date() and Time() functions.   And Mike notes that language design is more of an Art than Science.

Bob Hamilton
Richardson, Texas USA

On Mon, Nov 15, 2010 at 2:58 PM, Connor Birch <[hidden email]> wrote:

On 15 Nov 2010, at 14:21, Bill Fenlason wrote:

If you [MC] haven't already done so, I hope you write an essay or blog entry on "How to Design a Programming Language".  With your experience and accomplishments, it should be a classic and required reading for all computer science student.

I second that!

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

The lineage of NetRexx seems clear enough.  NetRexx incorporates many of the ideas of REXX.  REXX, of course, considerably predates Java.  NetRexx, on the other hand was created precisely to leverage Java and cannot predate it.  Without Java, what would distinguish REXX and NetRexx?  [Interestingly, Object REXX is also an object-oriented language influenced by REXX, and actually predates NetRexx.  Apparently MFC did not think it was "the answer."]

The lack of Date() and Time() is not very astonishing.  NetRexx is a one man creation and Mike has indicated that he was time constrained.  There wasn't time to rewrite the world, and the basic language allows access to powerful Java classes doing the same things, though not as conveniently.  They are, however,  more than up to the task of writing Date() and Time() routines in whatever format you like.

This doesn't mean that Date() and Tim() shouldn't be in NetRexx, simply that that step had to be deferred.  My understanding, from posts to this forum, is that at least one class library exists that makes a good fist at incorporating these and other REXX functionality.

George Hovey
Baltimore

On Sat, Apr 2, 2011 at 9:11 AM, Robert Hamilton <[hidden email]> wrote:

In my edition of TNRL, p. 8 are some comments along these lines. One factor to be aware of is the "astonishment factor" and, for me, one such is the lack of  Date() and Time() functions.   And Mike notes that language design is more of an Art than Science.

Bob Hamilton
Richardson, Texas USA

On Mon, Nov 15, 2010 at 2:58 PM, Connor Birch <[hidden email]> wrote:

On 15 Nov 2010, at 14:21, Bill Fenlason wrote:

If you [MC] haven't already done so, I hope you write an essay or blog entry on "How to Design a Programming Language".  With your experience and accomplishments, it should be a classic and required reading for all computer science student.

I second that!

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[billfen]

And a challenging Art at that.  I'm having fun designing a new type of programming language - my respect for the process has been expanded.

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

It has now been three years since IBM and RexxLA announced (in April 2008) that the NetRexx source would be opened.

Author MFC has been retired for more than a year.  (Congratulations to Mike!)

As the owner of NetRexx, IBM continues to break it's promise.  The last public information from IBM (as far as I can determine) was the 2009 RexxLA symposium presentation by Virgil Hein (Business Executive, IBM OS/2 and Office Products).  It is interesting that there was no published report from the 2010 symposium - a sign of no progress.

Obviously the IBM OSSC (open source committee?) has a formal process.  I suspect that it requires RexxLA to take specific actions or provide specific resources, and that has not been done. 

The lack of action in three years implies that neither IBM nor RexxLA are serious, and both are hoping that no one remembers the public promise.  Far easier for each side to cry poverty or point at the other side than to do the work.  Shame on both.

It is a sad state of affairs.  NetRexx deserves a better fate than to die off in obscurity.

Bill


On 4/2/2011 9:11 AM, Robert Hamilton wrote:

In my edition of TNRL, p. 8 are some comments along these lines. One factor to be aware of is the "astonishment factor" and, for me, one such is the lack of  Date() and Time() functions.   And Mike notes that language design is more of an Art than Science.

Bob Hamilton
Richardson, Texas USA

On Mon, Nov 15, 2010 at 2:58 PM, Connor Birch <[hidden email]> wrote:

On 15 Nov 2010, at 14:21, Bill Fenlason wrote:

If you [MC] haven't already done so, I hope you write an essay or blog entry on "How to Design a Programming Language".  With your experience and accomplishments, it should be a classic and required reading for all computer science student.

I second that!

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[ThSITC]

May I add (again) that Rexx2Nrx (see www.thsitc.com/Rexx2Nrx) *does* implement Rexx Date() and Time() ...
Thomas Schneider.
===================================================================================
Am 02.04.2011 16:52, schrieb George Hovey:

The lineage of NetRexx seems clear enough.  NetRexx incorporates many of the ideas of REXX.  REXX, of course, considerably predates Java.  NetRexx, on the other hand was created precisely to leverage Java and cannot predate it.  Without Java, what would distinguish REXX and NetRexx?  [Interestingly, Object REXX is also an object-oriented language influenced by REXX, and actually predates NetRexx.  Apparently MFC did not think it was "the answer."]

The lack of Date() and Time() is not very astonishing.  NetRexx is a one man creation and Mike has indicated that he was time constrained.  There wasn't time to rewrite the world, and the basic language allows access to powerful Java classes doing the same things, though not as conveniently.  They are, however,  more than up to the task of writing Date() and Time() routines in whatever format you like.

This doesn't mean that Date() and Tim() shouldn't be in NetRexx, simply that that step had to be deferred.  My understanding, from posts to this forum, is that at least one class library exists that makes a good fist at incorporating these and other REXX functionality.

George Hovey
Baltimore

On Sat, Apr 2, 2011 at 9:11 AM, Robert Hamilton <[hidden email]> wrote:

In my edition of TNRL, p. 8 are some comments along these lines. One factor to be aware of is the "astonishment factor" and, for me, one such is the lack of  Date() and Time() functions.   And Mike notes that language design is more of an Art than Science.

Bob Hamilton
Richardson, Texas USA

On Mon, Nov 15, 2010 at 2:58 PM, Connor Birch <[hidden email]> wrote:

On 15 Nov 2010, at 14:21, Bill Fenlason wrote:

If you [MC] haven't already done so, I hope you write an essay or blog entry on "How to Design a Programming Language".  With your experience and accomplishments, it should be a classic and required reading for all computer science student.

I second that!

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Thomas,
Your link returned "The requested URL was not found on this server."
George

On Wed, Apr 6, 2011 at 10:59 AM, Thomas Schneider <[hidden email]> wrote:

May I add (again) that Rexx2Nrx (see www.thsitc.com/Rexx2Nrx) *does* implement Rexx Date() and Time() ...
Thomas Schneider.
===================================================================================
Am 02.04.2011 16:52, schrieb George Hovey:

The lineage of NetRexx seems clear enough.  NetRexx incorporates many of the ideas of REXX.  REXX, of course, considerably predates Java.  NetRexx, on the other hand was created precisely to leverage Java and cannot predate it.  Without Java, what would distinguish REXX and NetRexx?  [Interestingly, Object REXX is also an object-oriented language influenced by REXX, and actually predates NetRexx.  Apparently MFC did not think it was "the answer."]

The lack of Date() and Time() is not very astonishing.  NetRexx is a one man creation and Mike has indicated that he was time constrained.  There wasn't time to rewrite the world, and the basic language allows access to powerful Java classes doing the same things, though not as conveniently.  They are, however,  more than up to the task of writing Date() and Time() routines in whatever format you like.

This doesn't mean that Date() and Tim() shouldn't be in NetRexx, simply that that step had to be deferred.  My understanding, from posts to this forum, is that at least one class library exists that makes a good fist at incorporating these and other REXX functionality.

George Hovey
Baltimore

On Sat, Apr 2, 2011 at 9:11 AM, Robert Hamilton <[hidden email]> wrote:

In my edition of TNRL, p. 8 are some comments along these lines. One factor to be aware of is the "astonishment factor" and, for me, one such is the lack of  Date() and Time() functions.   And Mike notes that language design is more of an Art than Science.

Bob Hamilton
Richardson, Texas USA

On Mon, Nov 15, 2010 at 2:58 PM, Connor Birch <[hidden email]> wrote:

On 15 Nov 2010, at 14:21, Bill Fenlason wrote:

If you [MC] haven't already done so, I hope you write an essay or blog entry on "How to Design a Programming Language".  With your experience and accomplishments, it should be a classic and required reading for all computer science student.

I second that!

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

--
Thomas Schneider (www.thsitc.com)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Fernando Cassia-2]

On Wed, Apr 6, 2011 at 2:14 PM, George Hovey <[hidden email]> wrote:
> Thomas,
> Your link returned "The requested URL was not found on this server."
> George

Oh yes, I noticed that a long time ago... three weeks I think. I think
the domain name has expired or something.

I was looking for rexx2nrx at the time...

FC
_______________________________________________
Ibm-netrexx mailing list
[hidden email]