Menu
▾
▴
#680 Allow mulitline cascading messages
If there is a large amount of cascading messages, it is natural to split them over lines.
Currently it is necessary in ooRexx to split the statement and supply trailing continuation characters (dash or comma).
*This would not be necessary, if ooRexx also allows the implicit continuation of a statement, if the first token on the next non-blank line is a tilde or a double tilde! *
This would allow one to write (artificial example) the statement
o~msg1~msg2(arg1,arg2,arg3)~msg3(a1,,a3)~~anotherMsg~~yetAnotherMsg(argument1,argument2)~~msga~msgb~msgc(a,b,c)
instead as:
o~msg1
~msg2(arg1,arg2,arg3)
~msg3(a1,,a3)
~~anotherMsg
~~yetAnotherMsg(argument1,argument2)
~~msga
~msgb
~msgc(a,b,c)
As the parser is reading the entire file it would be possible to ease breaking
up cascading messages without forcing in this context a trailing continuation
character.
Currently one only would be able to break cascading messages over multiple lines
by coding, e.g.
o~msg1,
~msg2(arg1,arg2,arg3),
~msg3(a1,,a3),
~~anotherMsg,
~~yetAnotherMsg(argument1,argument2)-
~~msga-
~msgb-
~msgc(a,b,c)
Comparing both versions of splitting cascading messages over multiple lines, I
think the latter version is more cumbersome for the programmer, but also more
difficult to read.
Related
Discussion
Anonymous
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
Whilst I agree with Rony that it is cumbersome to have to provide the continuation characters and more difficult to read, I feel that consistency is important.
I think it is correct to say that In rexx continuation characters are always required when clauses are split. The only exception being multiline comments.
There are other places where an implied continuation character would be usefull, for instance within the argument calls to a function, routine, or method
I quite often code
ret = method1( argument1 - , argument2 - , argument3 )for readability and entering that would also benefit from auto-continuation, but I recognise that having exceptions like this has a cost in terms of syntax consistency.
I'm not voting this proposal down, but pointing out that there is a drawback to be weighed in the balance.
Jon
PS: The code sample above lines up in the sourceforge preview, but I think will be unaligned in the mailing of any who are following this list.
I agree with Jon, with more weight given to syntax consistency. Plus, saving one continuation
character hardly seems worth the effort of Development, what with test cases and all else.
Well, the syntax consistency remains in place, as this RFE does not suggest an exception, rather it suggests an additional rule for future versions of ooRexx that help the programmers to forgo the line continuation character in the sole case of cascading messages.
No existing code nor test cases etc. would have to be changed.
Cascading messages become more and more common and for better legibility programming languages like C++, Java, C#, Javascript etc. split them up over multiple lines using indentation to line them up. It has become commong, that five, ten (sometimes even more) cascading invocations get coded in those languages. This is possible in those languages, because they define the end of such statements by the semi-colon, which is a mandatory token there.
This trailing semi-colon was forgone by Rexx (and some other languages) to ease programming. This "saves one ... character" and it was deemed to be worth the effort all along! And it has been appreciated by many Rexx programmers to not have been enforced to write the semi-colon to end a statement.
Rexx implies a semi-colon by a simple rule: if a semi-colon is missing, then the interpreter adds it at the end of a line. Should the programmer see a need to split a statement over multiple lines then he must supply a trailing comma or a trailing dash to indicate that the statement continues. Judging from many Rexx programs over the years, this possibilty has not been employed very heavily in the past, so the need for this has never been very high.
Now contrast this to the way modern object-oriented languages get employed by programmers who have started to using multi-line statements more and more heavily. There are quite a few programming patterns that encourage this style of programming which is seen to be powerful and easy to grasp. Cascading function invocations are being employed more and more, distributing them for better legibility over many (sometimes many, many) lines.
For BSF4ooRexx, but also for the new .Net support there, transcribing nutshell examples written in Java or C# to ooRexx is currently only possible, if using the continuation character, which barely have been used in classic Rexx. This forces one to add either a dash or a comma as the last character, which does not feel "natural" seeing how Java or C# are able to easily spread out their cascading of functions.
Take the C++ example from https://en.wikipedia.org/wiki/Fluent_interface:
FluentGlutApp(argc, argv) .withDoubleBuffer() .withRGBA() .withAlpha() .withDepth() .at(200, 200).across(500, 500) .named("My OpenGL/GLUT App") .create();translated to ooRexx:
FluentGlutApp~new(argc, argv) - ~withDoubleBuffer() - ~withRGBA() , ~withAlpha() - ~withDepth() , ~at(200, 200) , ~across(500, 500) - ~named("My OpenGL/GLUT App") - ~createShow these two snippets to a C++, a Java, a C# programmer and ask them which version seems to be easier (more natural). It will be clear that they rightfully point at the C++ version.
This RFE requets an additional rule for statement continuation in ooRexx only for taking advantage of cascading messages:
if there is no semi-colon at the end of line and there is a trailing dash or comma, then the statement is continued on the next line,
if there is no semi-colon at the ond of line and the next (non-blank) line starts out with a tilde (~) [or double-tilde (~~)] then regard the next line to be a continuation of the statement,
* otherwise imply a semi-colon at the end of line
Therefore this RFE would allow a 1:1 translation of cascading invocations in Java and .NET to ooRexx' cascading messages, allowing one to write instead:
FluentGlutApp~new(argc, argv) ~withDoubleBuffer() ~withRGBA() ~withAlpha() ~withDepth() ~at(200, 200) ~across(500, 500) ~named("My OpenGL/GLUT App") ~createAnd taking advantage of another ooRexx feature, that if a message carries no arguments one can forgo the parantheses:
FluentGlutApp~new(argc, argv) ~withDoubleBuffer ~withRGBA ~withAlpha ~withDepth ~at(200, 200) ~across(500, 500) ~named("My OpenGL/GLUT App") ~createThe latter version being even a nice simplification over the C++ version, that is easier legible.
I didn't imply that *existing* code or test cases would have to change, but obviously new test cases would have to be generated, as well as new documentation and perhaps
changes to existing docs, where appropriate.
Your arguments are certainly compelling, but I fear that the changes necessary for ooRexx to
look-ahead to the next source line would be a major impact.
Les,
When you say major impact, do you mean would require a lot of development,
or would have an impact on interpret-time performance? If the latter, I'd
value technical opinions on that. It might increase tokenisation time at
start-up, but is that even noticeable. I have some quite large scripts,
tokenised each time they are run and never notice any lag at all. Are we
talking about adding milliseconds or microseconds? It would be interesting
to have an informed opinion as the scan ahead would have to be done for
every line of every script whether or not they took advantage of this
feature.
Although you might be correct, I notice this comment in the parser:
// multiple line case...sigh.
Jon
On 21 November 2016 at 22:47, LesK vmrexx@users.sf.net wrote:
Related
Feature Requests: #680
I would like to second the importance of consistency. If we allow this "additional rule" for the ~/~~ operators, what is to prevent a request for also allowing it for other operators, say ||, to ease construction of very long strings?
It seems to me that Mike made the choice to imply semi-colons by line-end rather than requiring them as in C, Java, etc. This choice means those languages don't have to indicate continuation while Rexx does. Adding this "additional rule" mixes those two paradigms which, I feel, is a bad idea.
Gil B.
Consistency is not jeopardized at all. The rule for the RFE is simple and straight forward: "a statement can be continued, if either the last character on the line is a dash (or a comma) or the first token on the next line is a message operator". It can't possibly be simpler and alleviates a problem for ooRexx that has become more and more cumbersome for Rexx programmers.
As I have been in the midst of creating nutshell examples for a student to create (totally portable) GUIs with JavaFx (part of Java since Java 1.7/7) and added (with a lot, a lot of effort) specific support to BSF4ooRexx to ease their task as much as possible, there are first "real-ooRexx" examples that demonstrate the problem (that has not been there in the past):
The reason for these cascading messages is to ease coding for the programmers. The programmers should not have to type over and over the receiver, so the Java people came up with clever ideas and have been applying programming patterns to the JavaFX library.
As Rexx (and ooRexx) has been shining because of its "human-centricness", new challenges should be addressed.
Allowing this RFE will remove the need for placing trailing dashes/commas in the case that statement continuation is obvious anyway as the next line starts with a message operator!
Owing to the Rexx design principle of "human-centricness" this proposal was created. It eases programming a lot, on can safely forgo typing (in this context totatally unneded) trailing dashes or commas, which looks actually quite awkward if you go thru the above code.
This RFE would introduce the option to forgo the current need to add trailing commas/dashes. I am quite confident such this option will be taken advantage of immediately after it gets available!
Besides, ooRexx has already implemented/changed some long-standing behaviours in the context of messages (which have not existed at the time classic Rexx was conceived), in order to ease coding for the programmer and to make the code easier to read, i.e. easier to maintain.
In classic Rexx, if you use a routine as a function, you must use parenthesis, if you want the routine invocation to be replaced by the function value, even in the case that one has no arguments to supply to the routine!
E.g. a one-liner snippet that extracts the last three characters in a string:
In ooRexx you could code this with messages like this:
Now, in the case of messages (which will cause the appropriate method routines to be invoked by the receiving object) there is an option breaking ;) the function-invocation rule in as it is allowed to forgo the parentheses in the case that they carry no arguments!
So the above message version can be (and is often, because simpler and easier to read) rewritten as:
That was a very clever and very human-centric (optional!) innovation that is being taken advantage of by all my students, because it is easier to write and easier to read (and to maintain because of that)!
~reverse() vs. ~reverse is a fine example of melding Classic and Object Rexx so either type of
programmer can work with what they are most familiar with, even though they *both* might think that their 'rules' are being broken. It would also seem to answer Gil's argument.
As a VM Dinosaur, my natural tendency is to respect the Early Rexx history when Mike was first
developing Rex on paper and then distributing Alpha, Beta and Tools versions throughout IBM via VNET. Finally resulting in Rexx becoming part of the VM product.
But now we have Open Object Rexx and my exposure to it, as both an observer and sometimes
author, leads to the realization that the Community can provide a faster and better feedback
cycle than IBM's formal Development cycle. Not as fast as the Rexx Forum we had back in the old days, but still interactive and responsive enough.
Pending furthe analysis of the effort & impact to the code, docs and test cases,
I support Rony's RFE.