Type | Wish | Status | built | Date | 3-Mar-2014 22:02 |
---|---|---|---|---|---|
Version | r3 master | Category | Native | Submitted by | BrianH |
Platform | All | Severity | minor | Priority | normal |
Summary | Remove /redo option from RETURN |
---|---|
Description |
RETURN/redo exposes an internal feature used by DO any-function. However, this feature does not need to be exposed, and exposing it in this way breaks the predictability of the basic Rebol evaluation model (aka the DO dialect). Here is a basic demonstration of RETURN/redo breaking Rebol: http://stackoverflow.com/a/14890302/2016426 Ladislav demonstrates using RETURN/redo to implement variable-length arguments. However, he also demonstrates exactly why we don't want to allow people to do this. His code is correct, but it also is so tricky that only people who can understand and develop programs at Ladislav's level would be able to safely use the feature at all. In attempting to show the usefulness of RETURN/redo, he's clearly demonstrated why we need it to go away. The reason that Rebol's basic evaluation model is predictable is that the number of arguments taken and their evaluation model can be determined from the spec block of the function you are evaluating. This means that the caller of a function will always have a way to know what their code will do, the order in which their expressions will be evaluated. This also goes for DO any-function, because the number of arguments taken when the redo is evaluated is always determined by the spec of the any-function, which is provided in the call to DO. Any function which takes a number of arguments which can be determined by the caller of the function is safe to use in Rebol's basic evaluation dialect. Even if the caller is calling a function value which was provided as a parameter or referenced indirectly, it still could know how many arguments will be taken by examining the function's spec. This can even be done by external code analysis tools. Even with optional parameters, as long as those options have to be specified as refinements in the function call (path expressions or APPLY), the caller can still predict what a function can do to their code. RETURN/redo, however, does not obey those constraints. It makes it possible to make functions which take a number of parameters which are determined by the callee, and not predictable by the caller. And this makes Rebol execution indeterminable. For that matter, even using RETURN/redo at all without making hard-to-debug errors requires Ladislav-level skills. This is not a feature that we need to make user-facing. It needs to be hidden in DO, and any other native functions that have the same constraints as DO. |
Example code |
Assigned to | n/a | Fixed in | r3 master | Last Update | 4-Mar-2014 06:47 |
---|
Comments | |
---|---|
(0004296)
BrianH 4-Mar-2014 05:02 |
Implemented in https://github.com/rebol/rebol/pull/198 |
Date | User | Field | Action | Change |
---|---|---|---|---|
4-Mar-2014 06:47 | BrianH | Fixedin | Modified | => r3 master |
4-Mar-2014 06:47 | BrianH | Status | Modified | pending => built |
4-Mar-2014 05:02 | BrianH | Description | Modified | - |
4-Mar-2014 05:02 | BrianH | Status | Modified | submitted => pending |
4-Mar-2014 05:02 | BrianH | Comment : 0004296 | Added | - |
3-Mar-2014 22:02 | BrianH | Ticket | Added | - |