REBOL3 tracker
  0.9.12 beta
Ticket #0002181 User: anonymous

Project:



rss
TypeWish Statusdismissed Date30-Oct-2014 21:28
Versionr3 master CategoryNative Submitted byfork
PlatformAll Severityminor Prioritynormal

Summary Remove /RETURN from QUIT...retake EXIT for terminate w/code
Description I was looking at QUIT in Red and observed it was different than Rebol's QUIT. Rebol says:

USAGE:
QUIT /return value /now

DESCRIPTION:
Stops evaluation and exits the interpreter.
QUIT is a native value.

REFINEMENTS:
/return -- Returns a value (to prior script or command shell)
value -- Note: use integers for command shell
/now -- Quit immediately

Red 0.4.3 currently uses integers only, but uses /RETURN that takes a parameter named STATUS.

REFINEMENTS:
/return
status [integer!] => Return an exit status.

There's already deprecation of /NOW in Rebol, and seeing QUIT/RETURN/NOW 100 is kind of repetitively comical.

Furthermore, I believe it's confusing to see something like QUIT/RETURN 100 because the refinement sounds like the invocation of a verb, when the verb of QUIT-ting has already been established. Because QUIT is much stronger than the language feature RETURN, it would be more sensible as QUIT/STATUS 100, especially as a code is returned in any case...so you're not injecting the idea of returning a value at all, just something that's not zero.

The Wikipedia article on the topic is titled "Exit status" (reinforcing the commonality of /STATUS), and may be a more helpful link to point people at than just saying "it's an integer for most shells".

My initial argument was to change the name of the refinement from /RETURN to /STATUS, but then I started thinking that EXIT is fairly ingrained from other languages. It would be more natural to choose some other word to mean "return from procedure with no result".

So my better proposal is to make QUIT defined as EXIT 0, and EXIT takes an integer-only code. That will scan better. Via #0002200, the current functionality of `exit` would be achieved by the more generalized `return void`.

I believe that with the elimination of /NOW and the push of the responsibility of "catching" a quit to CATCH/QUIT means it should actually be CATCH/EXIT. Narrowing EXIT to integer codes makes sense as no script is built to call QUIT with the assumption that it was called by a script...if it had that assumption, it would use THROW and have a higher level protocol.
Example code
>> help quit

USAGE:
    QUIT

DESCRIPTION:
    Stops evaluation and exits the interpreter with a status code of 0
    QUIT is a function value.

>> source quit
quit: make function! [[
    {Stops evaluation and exits the interpreter with a status code of 0.}
][
    exit 0
]]

>> help exit

USAGE: 
EXIT status 

DESCRIPTION: 
Stops evaluation and exits the interpreter, returning a status code. 
EXIT is a native value. 

ARGUMENTS 
status -- Varies by platform, see http://en.wikipedia.org/wiki/Exit_status (integer!) 

Assigned ton/a Fixed in- Last Update5-Mar-2015 16:27


Comments
(0004537)
abolka
31-Oct-2014 05:08

While I agree that "exit code" or "status code" are slightly more prevalent forms, my perception is, that "return code" is similarly prevalent (and a quick comparison in Google trends [1] seems to at least not totally dismantle that perception). Further, `QUIT/return x` reads rather naturally as "quit and return x". Thus, I don't think a change in naming is really needed.
(0004538)
abolka
31-Oct-2014 05:16

Being more strict about the types accepted as return values is certainly an idea worth thinking about. At the "Rebol to outside world" communication border, this would most likely simplify things a bit (such as the interpreter having to decide what to return as exit code for QUIT/return "foo" on operating systems only accepting numeric exit codes).

We would loose the DO/args & QUIT/return combo for Rebol-to-Rebol communication. I don't have any strong indicators at how prevalent that use case is.
(0004539)
fork
31-Oct-2014 05:28

> `QUIT/return x` reads rather naturally as "quit and return x".

I'd disagree that is natural, and I think if one did surveys it would be hard to get people unfamiliar with the territory to know what that meant. More critically I think the severity and culture around the EXIT word is misplaced as a peer for RETURN.

I've revised the proposal to the better idea.
(0004564)
fork
1-Feb-2015 20:04

Wanted to add that after having used this in practical experience, I really like it, except for one thing it points out (which isn't particular to this, but a general principle of design in Rebol/Red).

I've mentioned the advantages already, but one thing that it does do, is it takes what could once be done with two words into something that takes three. And there is a property of the third word that it takes away, in that it sort of takes away *two* words. Because END is a part of a pairing with BEGIN, which has no current usage.

So if you are looking for simple clear variable names for pairings, giving END a meaning sort of takes away both BEGIN and END. *It's not a new problem. But with proposals like changing the "undesirable" variable name LENGTH? to LENGTH it is fodder for debate about the encroachment upon words people might want to use for variables, and to ask what kind of position paper there is in a "language with no keywords" about how much of the common space has a territory marker on it.
(0004589)
fork
5-Mar-2015 15:23

Pursuant to #0002200 and my own personal experience with it, I do not think taking END for this purpose and away from variables is a judicious choice. The better choice is use `return void`.

However, I think the arguments in favor of EXIT and QUIT being broken down in this way remain...even though these are separate issues. One could merely eliminate exit and keep QUIT as is and solve one axis of the problem. But I still dislike `quit/return` as being a kind of confusing double-verb.
(0004591)
BrianH
5-Mar-2015 15:43

Dismissed in favor of #2200, which is less intrusive. I agree: EXIT only means quit and return a code to people who have a background in C-like APIs or languages that emulate them. If you don't have that kind of background it doesn't make a bit of sense. Best to leave the C assumptions to the native and extension implementors; don't force them on the users.
(0004595)
fork
5-Mar-2015 16:27

QUIT/STATUS is still better than QUIT/RETURN.

Date User Field Action Change
5-Mar-2015 16:27 Fork Comment : 0004595 Added -
5-Mar-2015 15:43 BrianH Status Modified submitted => dismissed
5-Mar-2015 15:43 BrianH Comment : 0004591 Added -
5-Mar-2015 15:25 Fork Code Modified -
5-Mar-2015 15:24 Fork Description Modified -
5-Mar-2015 15:24 Fork Summary Modified Remove /RETURN from QUIT...change EXIT to END and then retake EXIT for terminate w/code => Remove /RETURN from QUIT...retake EXIT for terminate w/code
5-Mar-2015 15:23 Fork Comment : 0004589 Added -
1-Feb-2015 20:04 fork Comment : 0004564 Added -
1-Nov-2014 00:00 Fork Comment : 0004539 Modified -
1-Nov-2014 00:00 Fork Comment : 0004534 Removed -
31-Oct-2014 23:59 Fork Code Modified -
31-Oct-2014 23:59 Fork Description Modified -
31-Oct-2014 23:59 Fork Summary Modified rename QUIT's /RETURN to /STATUS, only accept integers => Remove /RETURN from QUIT...change EXIT to END and then retake EXIT for terminate w/code
31-Oct-2014 05:28 fork Comment : 0004539 Added -
31-Oct-2014 05:16 abolka Comment : 0004538 Added -
31-Oct-2014 05:08 abolka Comment : 0004537 Added -
30-Oct-2014 22:26 fork Comment : 0004534 Modified -
30-Oct-2014 22:24 fork Comment : 0004534 Added -
30-Oct-2014 21:29 fork Code Modified -
30-Oct-2014 21:29 fork Code Modified -
30-Oct-2014 21:29 fork Description Modified -
30-Oct-2014 21:28 fork Ticket Added -