Page 2 of 3

Re: ARexx "not not" bug

PostPosted: Sun Apr 23, 2017 1:59 pm
by broadblues
polluks wrote:Sorry guys, all prefix operators are broken:
Code: Select all
say --1
say ++1

If you take a look in the "bible":
"There may be one or more prefix operators to the left of any term."
https://books.google.de/books?hl=de&id= ... refix+plus

C'mon, our implementation is not a decision by design but simply incomplete.
It's slower, you have to parse extra parentheses.


But we don't have an implmentation of IBM Rexx we have an implemenation of ARexx, it's a seperate language, with different constructs, the time loss in dealing with brackets must be fairly trivial overall, especially when you will often end waiting for a command passed to a host via address to return.

What do you need 'not not' for anyway? It seems a bit redundant.

Re: ARexx "not not" bug

PostPosted: Sun Apr 23, 2017 4:29 pm
by xenic
polluks wrote:If you take a look in the "bible":

You're looking at the wrong "bible". The "bible" for ARexx is "ARexx Users Reference Manual 1.0" by William S. Hawes (the author of Amiga ARexx). It's a moot point anyway. There are no plans to ever change/update OS4 ARexx.

Re: ARexx "not not" bug

PostPosted: Sun Apr 23, 2017 10:19 pm
by nbache
thomasrapp wrote:What sense does it make to invert an inverting operator? Instead of ~~0 you could write just 0. Would be even faster, no operator to parse at all.
Of course ~~0 doesn't give any benefits. But as salass00 pointed out earlier in the thread, ~~x could be used to "normalize" the value of x to a (boolean-like) 0 or 1, like it is commonly done in e.g. JavaScript.

Best regards,

Niels

Re: ARexx "not not" bug

PostPosted: Sun Apr 23, 2017 11:34 pm
by polluks
broadblues wrote:But we don't have an implmentation of IBM Rexx we have an implemenation of ARexx, it's a seperate language, with different constructs, the time loss in dealing with brackets must be fairly trivial overall, especially when you will often end waiting for a command passed to a host via address to return.

However I have to write a bug report for Regina (http://regina-rexx.sourceforge.net) because its ARexx mode is not compatible.
The other way around seems to be more logical IMHO.

xenic wrote:There are no plans to ever change/update OS4 ARexx.

Too late, see viewtopic.php?f=14&t=3309.

Re: ARexx "not not" bug

PostPosted: Mon Apr 24, 2017 12:38 am
by broadblues
polluks wrote:
broadblues wrote:But we don't have an implmentation of IBM Rexx we have an implemenation of ARexx, it's a seperate language, with different constructs, the time loss in dealing with brackets must be fairly trivial overall, especially when you will often end waiting for a command passed to a host via address to return.

However I have to write a bug report for Regina (http://regina-rexx.sourceforge.net) because its ARexx mode is not compatible.
The other way around seems to be more logical IMHO.


Well why does regina need bug report, if it supports both ~~0 and ~(~0) it's a superset of ARexx. No problem. How many rexx scripts actually run on both AmigaOS and AROS? Exact compatabilty would seem overkill, and if needed easily obtained by avoiding obscure edge cases in the syntax that stayed hidden for 30 years as you put it earlier :-)


I would guess modify Arexx's parser would be non trivial.

Re: ARexx "not not" bug

PostPosted: Wed Apr 26, 2017 2:14 pm
by zzd10h
"~~ also works in Rexx on IBM mainframe."

yes.

Re: ARexx "not not" bug

PostPosted: Thu Apr 27, 2017 12:09 am
by polluks
zzd10h wrote:yes.

Thanks. Indeed, it's rather academic.
BTW Regina has "options AREXX_SEMANTICS".

Re: ARexx "not not" bug

PostPosted: Sat Apr 29, 2017 8:55 pm
by polluks
Guess the result:
Code: Select all
say 10-1
say 10--1
say 10---1

Re: ARexx "not not" bug

PostPosted: Sat Apr 29, 2017 9:19 pm
by broadblues
polluks wrote:Guess the result:
Code: Select all
say 10-1
say 10--1
say 10---1


say 10+--1 is equally interesting

Re: ARexx "not not" bug

PostPosted: Thu Jun 15, 2017 1:35 am
by ssolie
xenic wrote:...There are no plans to ever change/update OS4 ARexx.

Incorrect.