Possible Language enhancements?

[Kermit Kiser]

There are a couple of problems that I run into frequently in my NetRexx
programming. Either I am doing things the hard way or there is a need
for some new language features.

1) Java docs tell me to initialize an integer field this way (where
ledARGB = int):      

ledARGB = 0xff00ff00

That does not seem to work in NetRexx for some reason (Error: Cannot
convert value of type 'long' for assignment to variable of type 'int')
so I have used the following work around:

ledARGB = 'ff00ff00'.x2d(8)

Is there a better way to do this? If not, can we add a language
enhancement to support this Java initialization format for integers?

2) Java docs often tell me to add a flag to an integer field of flags
with a simple binary OR operation like this (where flags=int and
FLAG_SHOW_LIGHTS is an integer containing some binary options):

flags = flags|FLAG_SHOW_LIGHTS

(actually they show the compressed format that NetRexx does not support:
flags |= FLAG_SHOW_LIGHTS but that is another issue)

The above instruction does not work properly for integers in NetRexx
unless the instruction is in a binary method so my work around is to
create my own binary OR operator as follows:

    flags = binaryOR(flags,FLAG_SHOW_LIGHTS)

where:

    method binaryOR(a=int,b=int) binary returns int

        return a|b      

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

I would like to add a NetRexx enhancement to allow the Java instruction
formats to work properly for integers in these cases. It might require
an OPTIONS mode because of the change to existing programs, but I don't
think it would interfere with current boolean operations much. In my
opinion this would improve interoperability with Java a lot. (Let me
know if there a better way to do these things!)

-- Kermit
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hi Kermit,

   ... long time ago (relating the *BINARY* AND, OR, and XOR *operators*
(and the MISS of them in NetRexx,
when *NOT* in the BINARY MODE) I discussed the same issue and said:

a) Rexx should support the *words* AND, OR, XOR  *as operators*
b) *and*, maybe BAND, BOR, BXOR (for the BINARY operators), as well ...

... But that has been years ago....

At those times, I was alwaays, switching languages (CONOL, PL/I, Rexx,
NetRexx) like a hell
wondering why:

(in classix Rexx)

if a=13 or b=3 then do ...

gives an UNEXPECTED RESULT (for me, stupid as I am)

In CLASSIC REXX:   (or, as undefined in the language, suddenly becomes
the string 'OR',
in classic Rexx (and ooRexx, as well) , and the system (Rexx and ooRexx)
BOMBS
(at run-time) ...

Thus, I would make AND, OR, *and* XOR *reserved words* .......

Full stop.
Thomas Schneider.

currently working on the Rey Compiler Release 1.00

Project 'reyc' there at www.kenai.com   (*JOIN when interested* :-)   !!!!

Greetings from dark Vienna (Austria, NO Kangurooos) ,
Tom.
==========================================================
Kermit Kiser schrieb:

> There are a couple of problems that I run into frequently in my
> NetRexx programming. Either I am doing things the hard way or there is
> a need for some new language features.
>
> 1) Java docs tell me to initialize an integer field this way (where
> ledARGB = int):      
> ledARGB = 0xff00ff00
>
> That does not seem to work in NetRexx for some reason (Error: Cannot
> convert value of type 'long' for assignment to variable of type 'int')
> so I have used the following work around:
>
> ledARGB = 'ff00ff00'.x2d(8)
>
> Is there a better way to do this? If not, can we add a language
> enhancement to support this Java initialization format for integers?
>
> 2) Java docs often tell me to add a flag to an integer field of flags
> with a simple binary OR operation like this (where flags=int and
> FLAG_SHOW_LIGHTS is an integer containing some binary options):
>
> flags = flags|FLAG_SHOW_LIGHTS
>
> (actually they show the compressed format that NetRexx does not
> support: flags |= FLAG_SHOW_LIGHTS but that is another issue)
>
> The above instruction does not work properly for integers in NetRexx
> unless the instruction is in a binary method so my work around is to
> create my own binary OR operator as follows:
>
>    flags = binaryOR(flags,FLAG_SHOW_LIGHTS)
>
> where:
>
>    method binaryOR(a=int,b=int) binary returns int
>
>        return a|b      
> ----------------------------------------------------------
>
> I would like to add a NetRexx enhancement to allow the Java
> instruction formats to work properly for integers in these cases. It
> might require an OPTIONS mode because of the change to existing
> programs, but I don't think it would interfere with current boolean
> operations much. In my opinion this would improve interoperability
> with Java a lot. (Let me know if there a better way to do these things!)
>
> -- Kermit
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[alansam]

On 28 April 2010 14:00, Kermit Kiser <[hidden email]> wrote:

There are a couple of problems that I run into frequently in my NetRexx programming. Either I am doing things the hard way or there is a need for some new language features.

1) Java docs tell me to initialize an integer field this way (where ledARGB = int):      
ledARGB = 0xff00ff00

That does not seem to work in NetRexx for some reason (Error: Cannot convert value of type 'long' for assignment to variable of type 'int') so I have used the following work around:

ledARGB = 'ff00ff00'.x2d(8)

Is there a better way to do this? If not, can we add a language enhancement to support this Java initialization format for integers?

This is discussed in more detail in NetRexx2.pdf "Hexadecimal and binary numeric symbols" section but the following works:

/* NetRexx */

options replace format comments java crossref savelog symbols

ledARGA = long
ledARGB = int

ledARGA = 0xff00ff00
ledARGB = 8xff00ff00

say 'ledARGA:' ledARGA Rexx(ledARGA).d2x(8)
say 'ledARGB:' ledARGB Rexx(ledARGB).d2x(8)

return

Results:
ledARGA: 4278255360 FF00FF00
ledARGB: -16711936 FF00FF00

Alan.

--
Needs more cow-bell!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[alansam]

On 28 April 2010 15:06, Thomas Schneider <[hidden email]> wrote:

Thus, I would make AND, OR, *and* XOR *reserved words* .......

Full stop.

As has been discussed on this and other lists ad nauseum, introducing "reserved words" into the REXX family of languages is a step back into the dark ages.  Not to mention a likely cause for many existing programs who innocently use these "reserved words" as variable names suddenly and randomly failing.

If you want to use this style of programming either overload the operators yourself (see Kermit's example above) or stick to COBOL.

Alan.

--
Needs more cow-bell!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Kermit Kiser]

Thanks for the info Alan. I missed that section - it's not in the older TNRL book. The 8x syntax is not completely Java compatible, but it may be close enough. It's much better than what I was using anyway. I will add a section with that information to the NetRexx at Once guide that Leonardo Boselli gave me permission to maintain.

-- Kermit

Alan Sampson wrote:

On 28 April 2010 14:00, Kermit Kiser <[hidden email]> wrote:

There are a couple of problems that I run into frequently in my NetRexx programming. Either I am doing things the hard way or there is a need for some new language features.

1) Java docs tell me to initialize an integer field this way (where ledARGB = int):      
ledARGB = 0xff00ff00

That does not seem to work in NetRexx for some reason (Error: Cannot convert value of type 'long' for assignment to variable of type 'int') so I have used the following work around:

ledARGB = 'ff00ff00'.x2d(8)

Is there a better way to do this? If not, can we add a language enhancement to support this Java initialization format for integers?

This is discussed in more detail in NetRexx2.pdf "Hexadecimal and binary numeric symbols" section but the following works:

/* NetRexx */

options replace format comments java crossref savelog symbols

ledARGA = long
ledARGB = int

ledARGA = 0xff00ff00
ledARGB = 8xff00ff00

say 'ledARGA:' ledARGA Rexx(ledARGA).d2x(8)
say 'ledARGB:' ledARGB Rexx(ledARGB).d2x(8)

return

Results:
ledARGA: 4278255360 FF00FF00
ledARGB: -16711936 FF00FF00

Alan.

--
Needs more cow-bell!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[alansam]

On 28 April 2010 17:39, Kermit Kiser <[hidden email]> wrote:

Thanks for the info Alan. I missed that section - it's not in the older TNRL book. The 8x syntax is not completely Java compatible, but it may be close enough. It's much better than what I was using anyway. I will add a section with that information to the NetRexx at Once guide that Leonardo Boselli gave me permission to maintain.

-- Kermit

Glad I could help.  The only reason I know about this feature of NetRexx is that I was struggling with this problem earlier this month.  Mike really introduced a nice little syntax improvement here that helps get past the lack of unsigned integers in Java.  If you look at the generated Java keep file you will see that the NetRexx compiler generates a decimal number (+ve or -ve) depending on the hex value's context so that Java contains the correct value.  Thanks Mike.

Alan.

--
Needs more cow-bell!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

You're welcome :-).   I admit I was quite pleased with that little extension, and wondered why no one else had thought of it...

 

Mike

Glad I could help.  The only reason I know about this feature of NetRexx is that I was struggling with this problem earlier this month.  Mike really introduced a nice little syntax improvement here that helps get past the lack of unsigned integers in Java.  If you look at the generated Java keep file you will see that the NetRexx compiler generates a decimal number (+ve or -ve) depending on the hex value's context so that Java contains the correct value.  Thanks Mike.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]