Talk:Flow-control structures: Difference between revisions
→REXX Return: an example showing all flavors
(Unicon/Icon - lengthy explanations on task page - where to put them?) |
Walterpachl (talk | contribs) (→REXX Return: an example showing all flavors) |
||
| (13 intermediate revisions by 6 users not shown) | |||
Line 17:
--[[User:Dgamey|Dgamey]] 23:54, 12 April 2010 (UTC)
The typical RC example is short on explanation. If you can say something informative about the code, ''please'' put it right on the page and not buried behind a link. —[[User:Kevin Reid|Kevin Reid]] 02:35, 13 April 2010 (UTC)
:: Please have a look at the Icon/Unicon example on this page it goes into great detail like I haven't seen on the site before. I'm asking a question about balance of explanation. What would really be helpful would be a couple of balanced examples. --[[User:Dgamey|Dgamey]] 03:54, 13 April 2010 (UTC)
== Rename to Branching structures and jumps ==
This task might be better named as "Branching structures and jumps". The term "flow control" is usually associated with data streams, and refers to things like hardwire hand shacking, xon/xoff pacing and ack/nak protocol.
[[User:Markhobley|Markhobley]] 14:29, 19 May 2011 (UTC)
== I have added the multi-processing JOB command to the MUMPS example ==
Since I think that generally, anything that initiates the flow of code, involving the program counter or stack pointer is part of Flow Control, I have included the JOB command that "duplicates" and initiates a different flow of control.
== REXX Return ==
The text does not consider the Return from a subroutine or function. It should! --[[User:Walterpachl|Walterpachl]] 17:12, 28 January 2013 (UTC)
::: The '''RETURN''' text has been updated. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 17:44, 17 December 2013 (UTC)
:::: What I see is wrong :-( Please reconsider the Return from a, internal subroutine or function! ..[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 18:39, 17 December 2013 (UTC)
::::: The RETURN text mentions "which could be a subroutine or function)" ... and passed control to the invoking program (the program that called or invoked the subroutine/function). If you think the phrase could use clarification, then feel free to add more verbage. It's sometimes not clear to readers what is being referred to which REXX code is being executed (or being called/invoked) when the REXX code calls/invokes an internal REXX program versus an external REXX program. This can be an area of misunderstanding, and certainly, an area of confusion. I'm not sure how to succinctly put that into words that is concise and easy to understand without getting to wording that is too obtuse. I don't want to re-write a REXX tutorial on the RETURN statement. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 19:07, 17 December 2013 (UTC)
--------------------------
How about this:
<pre>RETURN returns control, and possibly a result, from a Rexx program or routine to the point of
its invocation.
If no internal routine (subroutine or function) is active,
RETURN and EXIT are identical in their effect on the program that is run. (See EXIT.)
If called as a function, an expression must be present, its value is returned to the point of
invocation.
If called as a routine, control is passed back to the caller.
If an expression is present, it is evaluated and the Rexx special variable RESULT is set
to the value of expression. Otherwise the special variable RESULT is dropped.</pre>
--[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 21:01, 17 December 2013 (UTC)
:::::: The following example shows all the flavors (and a surprise when I invoke the program as rexx ret 1 (on Windows using ooRexx)! The control structure seems to get broken)
<lang rexx>Call sub 1
s=sub(2)
Say 's='s
sub: parse Arg a
Select
When a=1 Then Say 'we''ll return to line 2'
When a=2 Then Say 'we''ll return to the expression in line 2'
Otherwise Say 'we''ll exit the program'
End
Return a</lang>
Output:
<pre>we'll return to line 2
we'll return to the expression in line 2
s=2
we'll exit the program</pre>
== REXX Exit ==
This sentence is incorrect (if the program with the exit is an external program)
<br>"If the invoking program is a REXX program, it also is terminated."
<br>consider
<lang rexx>/* Caller */
say 'I am the Caller'
Call called
Say 'and back in Caller. Got' result 'from Called'</lang>
<lang rexx>/* Called.rex */
say 'I am Called'
Say 'Now I am going to Exit'
Exit 4711</lang>
Output:
<pre>I am the Caller
I am Called
Now I am going to Exit
and back in Caller. Got 4711 from Called</pre>
--[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 09:24, 17 December 2013 (UTC)
::: The '''EXIT''' text has been updated. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 17:39, 17 December 2013 (UTC)
-----
: And an additional idea/question: ooRexx has Call on exception handling (similar to Signal On). Do other Rexxes have that too?? --[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 09:28, 17 December 2013 (UTC)
| |||