Ticket #0002121

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

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	-