This really won't work, particularly now that oorexx has the shortcut
syntax for array creation. To start with, it is an absolute nightmare for
syntax error reporting and parsing because it is impossible to know what
situation you are working with until parsing is completely finished. For
example,
cal xl(a + b)
has one meaning for the parens while
call x(a + b) * c
has a completely different one. It is not possible to determine what the
situation is until parsing of the argument list is complete.
Also, now that oorexx has the array shortcut syntax, it introduces an
incompatibility. Currently,
call x(a,b)
is a call to X passing a single array argument. This change would cause
this to call X passing two arguments instead.
I consider this to be a change that causes all sorts of syntax definition
problems while offering no real functional value to the language.
Rick
On Sun, Feb 21, 2016 at 6:07 AM, Erich Steinböck <[email protected]
> wrote:
> In Rexx we typically have this well-known distinction between a function
> call and a "procedure" CALL. The former requiring brackets, the latter
> won't accept brackets.
>
> say lineout(.stdout, "line")
> call lineout .stdout, "line"
>
> On the other hand, with ooRexx message terms (and also in other languages
> like C) I learned to love the more simpler forms - both of which with
> brackets
>
> written = .stdout~lineOut("line")
> .stdout~lineOut("line")
>
> Sometimes, when switching a line of code from the function to the CALL
> form, I forget about removing the brackets, and I'm left with e. g.
>
> call lineout(.stdout)
> call lineout(.stdout, "line")
>
> (Somewhat surprisingly) the single-argument form CALL function(arg) works
> as expected, and the multiple-argument form CALL function(arg1, arg2, ..
> argn) used to give Error 37.1: Unexpected "," for Rexx before 5.0.
> Starting with Rexx 5.0, due to the new array term syntax, CALL
> function(arg1, arg2, .. argn) is interpreted as CALL function
> .Array~of(arg1, arg2, .. argn)~makeString and may or may not fail
> depending on function() but will most surely not do what was intended.
>
> (The example call lineout(.stdout, "line") quietly does nothing, most
> probably because Cr/Lf character aren't supported in a filename).
>
> With above said, I'm proposing to allow
> CALL function(arg1, arg2, .., argn)
> (with no space between function and the bracket) to be functionally
> equivalent to
> CALL function arg1, arg2, .., argn
>
> I believe that this change - if done before 5.0 is released - should not
> break existing code.
>
> What do you think?
> Pros and cons, anyone?
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
