NetRexx enhancements -- reply

classic Classic list List threaded Threaded
104 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|

RE: NetRexx enhancements -- reply

Mike Cowlishaw
Yes, a special symbol name seems analogous to 'this', 'ask' etc and in the spirit of NetRexx.  But doesn't this raise the possibility of breaking programs?   
 
No.
 
Coming (originally) from a FORTRAN background, where keywords were not reserved -- the line "IF IF(CALL) THEN CALL CALL(IF)" would happily compile (as, incidentally, would "IFIF(CALL)THENCALLCALL(IF) ") -- this fragility of modern languages strikes me as having unfortunate consequences.  Isn't fear of new reserved words the reason that STATIC is so abused?

Would it make sense to have a special class of symbols reserved for the compiler, say using initial '_' or whatever?   This also may break programs, but only once.   The ability to safely introduce new keywords could be a lifesaver as NetRexx evolves.

No need -- you can add as many special names and keywords to NetRexx as you like without breaking a single program.  If the a program is already using the symbol as the name of a variable, it will continue to be the name of a variable.   That's one of the key distinguishing features of NetRexx (and absolutely essential for any language designed to be executable from source).
 
None of the existing 'special names' (or keywords) in NetRexx are reserved.  You can perfectly well use:
 
  ask=3
  say ask
 
and '3' will be displayed.  Of course you cannot use 'ask' to have the special side-effect after that point ... but if you were intending to do that (i.e., knew about the special name 'ask') then you'de be unlikely to use it as a variable name.   This is also a significant difference from the FORTRAN approach.
 
Mike
 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

George Hovey-2
Ah so.

On Thu, Sep 30, 2010 at 10:17 AM, Mike Cowlishaw <[hidden email]> wrote:
Yes, a special symbol name seems analogous to 'this', 'ask' etc and in the spirit of NetRexx.  But doesn't this raise the possibility of breaking programs?   
 
No.
 
Coming (originally) from a FORTRAN background, where keywords were not reserved -- the line "IF IF(CALL) THEN CALL CALL(IF)" would happily compile (as, incidentally, would "IFIF(CALL)THENCALLCALL(IF) ") -- this fragility of modern languages strikes me as having unfortunate consequences.  Isn't fear of new reserved words the reason that STATIC is so abused?

Would it make sense to have a special class of symbols reserved for the compiler, say using initial '_' or whatever?   This also may break programs, but only once.   The ability to safely introduce new keywords could be a lifesaver as NetRexx evolves.

No need -- you can add as many special names and keywords to NetRexx as you like without breaking a single program.  If the a program is already using the symbol as the name of a variable, it will continue to be the name of a variable.   That's one of the key distinguishing features of NetRexx (and absolutely essential for any language designed to be executable from source).
 
None of the existing 'special names' (or keywords) in NetRexx are reserved.  You can perfectly well use:
 
  ask=3
  say ask
 
and '3' will be displayed.  Of course you cannot use 'ask' to have the special side-effect after that point ... but if you were intending to do that (i.e., knew about the special name 'ask') then you'de be unlikely to use it as a variable name.   This is also a significant difference from the FORTRAN approach.
 
Mike
 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]




_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Thomas.Schneider.Wien
In reply to this post by George Hovey-2
Hello George,
   many of my original programs have been written in Fortran 77, too.

NetRexx does have a *very clever* algorithm to distinguish between keywords
and variables.

if you are using a keyowrd in an assignment,e,g.

   if=3

... then it does become a variable!

Heve never tested wether

   if if then a=3

is accepted or not ...

The only problem I did find with this approach was a method where I did code

method mymethod(from,to) static

loop i=from to to

which failed to compile....

... hence I used xfrom, xto for the parameter names.

Same holds true with ask, for instance.

If you code:

ask='abc def'

you may no longer use the 'special symbol' ask, e.g.

parse ask a '  '  b

will parse your variable ask, NOT ask you.

Very clever...

Mike, when I did explain it wrong, please do correct me...

Thomas.
=========================================================

Am 30.09.2010 14:53, schrieb George Hovey:
Yes, a special symbol name seems analogous to 'this', 'ask' etc and in the spirit of NetRexx.  But doesn't this raise the possibility of breaking programs?  Coming (originally) from a FORTRAN background, where keywords were not reserved -- the line "IF IF(CALL) THEN CALL CALL(IF)" would happily compile (as, incidentally, would "IFIF(CALL)THENCALLCALL(IF) ") -- this fragility of modern languages strikes me as having unfortunate consequences.  Isn't fear of new reserved words the reason that STATIC is so abused?

Would it make sense to have a special class of symbols reserved for the compiler, say using initial '_' or whatever?   This also may break programs, but only once.   The ability to safely introduce new keywords could be a lifesaver as NetRexx evolves.

On Thu, Sep 30, 2010 at 4:48 AM, Mike Cowlishaw <[hidden email]> wrote:
 
 George wrote
 
 Chip, I included a program on the super-long thread which escaped notice, except by Bill.  It is  [snipped] 


|  y = x  = 1     -- ie, y = the value of the proposition 'x  = 1'

The point of this example is to show that MFC's idea for x+=1 becomes x=~+1  becomes x==+1 may have a fatal flaw.  It seems to me that with MFC's rule in effect, the 2nd and 3rd lines cannot be parsed because there a two possible interpretations of the second '='.   
 
I missed that example too -- lots of posts recently!   Sorry.
 
My idea for using '=' as meaning 'the left hand side of the assignment' assumed that it would only mean that if otherwise the '=' would be an error.  So no existing meaning would change.
 
However, from a language point of view it might be better not to use an 'operator character' or 'special character' at all, because the thing we are substituting for is a symbol.  For example, one could use the underscore (currently the only non-alphanumeric character required to be in the set of symbol characters).   Happily this could be added without breakage using the usual rule that if '_' is already in use as the name of a variable then it is a reference to that variable, not the special meaning.
 
  longvarname=_+1
 
Perhaps that doesn't look so good -- but of course a keyword (special name) could be used instead, for example:
 
 longvarname=it+1
 
but that might be more confusing unless a good special name is chosen.
 
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]

Tom. (ths@db-123.com)
Reply | Threaded
Open this post in threaded view
|

Re: NetRexx enhancements -- reply

Thomas.Schneider.Wien
In reply to this post by Mike Cowlishaw
Whoops, Mike, just did respond to George before reading your response. :-(

May I only add that ordinary regular expression based editors (like JEdit) will still
colour the symbol you did use as if it would be a keyword .... But that is another
story...

Anyway, it's a very clever algorithm.

It's also interesting, that

a=boolean 1
if(a) ...  -- note: NO blank after the if

is NOT an IF-statement, but an invokation of the method 'if' in NetRexx.

Clever design ... :-)
 
Thomas.
===========================================================
Am 30.09.2010 16:17, schrieb Mike Cowlishaw:
Yes, a special symbol name seems analogous to 'this', 'ask' etc and in the spirit of NetRexx.  But doesn't this raise the possibility of breaking programs?   
 
No.
 
Coming (originally) from a FORTRAN background, where keywords were not reserved -- the line "IF IF(CALL) THEN CALL CALL(IF)" would happily compile (as, incidentally, would "IFIF(CALL)THENCALLCALL(IF) ") -- this fragility of modern languages strikes me as having unfortunate consequences.  Isn't fear of new reserved words the reason that STATIC is so abused?

Would it make sense to have a special class of symbols reserved for the compiler, say using initial '_' or whatever?   This also may break programs, but only once.   The ability to safely introduce new keywords could be a lifesaver as NetRexx evolves.

No need -- you can add as many special names and keywords to NetRexx as you like without breaking a single program.  If the a program is already using the symbol as the name of a variable, it will continue to be the name of a variable.   That's one of the key distinguishing features of NetRexx (and absolutely essential for any language designed to be executable from source).
 
None of the existing 'special names' (or keywords) in NetRexx are reserved.  You can perfectly well use:
 
  ask=3
  say ask
 
and '3' will be displayed.  Of course you cannot use 'ask' to have the special side-effect after that point ... but if you were intending to do that (i.e., knew about the special name 'ask') then you'de be unlikely to use it as a variable name.   This is also a significant difference from the FORTRAN approach.
 
Mike
 
_______________________________________________ Ibm-netrexx mailing list [hidden email]


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

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Tom. (ths@db-123.com)
1 ... 3456