Type | Wish | Status | reviewed | Date | 5-Mar-2015 15:17 |
---|---|---|---|---|---|
Version | r3 master | Category | Native | Submitted by | fork |
Platform | All | Severity | minor | Priority | normal |
Summary | Add VOID function to return an #[unset!], eliminate EXIT in favor of RETURN VOID |
---|---|
Description |
While generating unsets may not seem to be a thing you'd want to make convenient, it turns out that the need to generate them does come up. At the end of a chain of evaluations, you might want to say "insert nothing", e.g. with COMPOSE: >> compose/only [foo (either condition [stuff] [#[unset!]]) bar] The desire to return an UNSET! from a function has been addressed by a variant of RETURN called EXIT. The confusing nature of EXIT as sounding to programmers like the POSIX `exit()` call makes it seem an odd choice for returning no value for a function. This is mentioned in #2181. However, as it happens...RETURN can already return ANY-TYPE!: USAGE: RETURN value DESCRIPTION: Returns a value from a function. RETURN is a native value. ARGUMENTS: value (any-type!) As a consequence, if there were a more literate way of creating UNSET! values it could eliminate the need for an EXIT, and also make other code that wished to make UNSET! values cleaner. Proposed generator would be called VOID: >> void: does [#[unset!]] As with returning other values from functions, a function that merely wished to return no value would not need to invoke RETURN at the end of their evaluation, but could just have their last statement be VOID |
Example code |
; Current behavior print-if-negative: function [value [integer!]] [ if value >= 0 [ exit ] print value ] ; Suggested behavior print-if-negative: function [value [integer!]] [ if value >= 0 [ return void ] print value ] |
Assigned to | n/a | Fixed in | - | Last Update | 5-Mar-2015 16:10 |
---|
Comments | |
---|---|
(0004590)
BrianH 5-Mar-2015 15:38 |
If we do the unsetting of EXIT, we should make it available in the 'old module (#2132). If you want EXIT to mean QUIT/return, that would be a good thing to put in the same module as things like CD and LS.
Nothing wrong with the VOID function though. It has to be a function rather than a constant because the constant would be overridden by any export of the word 'void from any module. |
(0004592)
fork 5-Mar-2015 15:47 |
A compatibility story for all code written to the older expectations is presumably a prerequisite for pretty much *any* breaking change, and it's a story that should have probably had a good way of telling prior to things like the FUNCTION remap from Rebol2 meaning...
The story hasn't been told yet (e.g. no R2/Backward yet). But better late than never. And maybe that would make people less resistant to newer/better ideas. |
(0004594)
BrianH 5-Mar-2015 16:10 |
R2/Backward will mostly be covered by the 'old module. I finally figured out how to do R2/Backward, and #2132 is the backwards-compatibility part. |
Date | User | Field | Action | Change |
---|---|---|---|---|
5-Mar-2015 16:11 | BrianH | Comment : 0004594 | Modified | - |
5-Mar-2015 16:11 | BrianH | Comment : 0004594 | Modified | - |
5-Mar-2015 16:10 | BrianH | Comment : 0004594 | Added | - |
5-Mar-2015 15:47 | Fork | Comment : 0004592 | Added | - |
5-Mar-2015 15:46 | BrianH | Category | Modified | Unspecified => Native |
5-Mar-2015 15:46 | BrianH | Status | Modified | submitted => reviewed |
5-Mar-2015 15:38 | BrianH | Comment : 0004590 | Added | - |
5-Mar-2015 15:28 | Fork | Code | Modified | - |
5-Mar-2015 15:20 | Fork | Description | Modified | - |
5-Mar-2015 15:18 | Fork | Description | Modified | - |
5-Mar-2015 15:17 | Fork | Description | Modified | - |
5-Mar-2015 15:17 | Fork | Type | Modified | Bug => Wish |
5-Mar-2015 15:17 | Fork | Ticket | Added | - |