Back out legality of x: (), CHECK-SET, SET+GET/OPT
#216
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With refinement arguments being unset by default, adapting bits of code
that had assumed they were NONE! required rewriting or a way to check
for a set state. Rather than NOT UNSET? the operation SET? was
added--with rationale that SET! would not be a data type (given MAP!
and other concerns) and that this was a common test.
A realization in chat while trying to find a more communicative name
for VALUE? led to this possibility:
>> set 'x 10
>> set? 'x
== true
>> unset 'x
>> unset? 'x
== true
It paints a rather clear picture that SET? and UNSET? might be seen as
operations on variables as opposed to values. (Bound words being the
closest thing Rebol has to representing "variables", as they are the
access points for both reads and writes.) However it also raises a
number of questions.
So whether that decision goes forward or not, it made it seem hasty at
this point in time to pre-decide on SET? as the opposite of UNSET?
for values. The ANY-VALUE! category typeset is already used in
function specs and considered "anything but UNSET!" (pending upcoming
change, it's still a synonym for ANY-TYPE! until #opt vs <opt> is
decided for function specs.)
Given that ANY-VALUE? is a safe bet, and may ultimately evolve into
simply VALUE? (if legacy uses can be corraled in relevant code or
given compatibility shims until they can be adapted), it replaces
SET? in this commit. There are few uses so best to back them out
now that the question exists before they become widespread.
The problem which allowing `x: ()` to not be an error was designed to address can be handled in a less system-breaking way with a primitive suggested by @earl, which is CHECK-SET...an arity-2 function that soft-quotes its first parameter, which is constrained to be either a set-word or a set-path: if check-set var: thing-that-may-be-unset [ ... ] Idiomatically this comes across reasonably well that var: is being set by this code. CHECK-SET does not come off most importantly as a query due to the lack of a question mark, rather as some form of setting that involves a check. Even if glossed as CHECK-SET? it still fits well, as it seems an assignment has happened whether you realize var: is a parameter to check-set or not. The promise of this option outweighs the loss in locality of error delivery given by allowing `x: ()`--hence that will be backed out shortly.
This was a long-pending modification being motivated by taking another step toward straightening out unsets. The /ANY refinement has no bearing on optional setting (and ANY has another much more common meaning) while the /OPT refinement corresponds directly to the idea of a value which can be unset as well as carry a range of other values. GET already had a legacy mezzanine to support its fallthrough of being able to get values like `get 3`, an ability that Red also did not carry forward. This moved SET out as well--which is forward-thinking based on the idea that the current interface of SET for setting objects positionally breaks the rule that objects aren't supposed to be accessed by position. Hence rather than pollute the core with a deprecated refinement this moves the refinement out. Having the versions of SET and GET be in user code will slow them down some, which is unfortunate...but it's a temporary state as the /ANY versions will be legacy mode after a sufficiently long time is given with /OPT being offered for code to adapt. There are also some pending designs for speeding up such wrappers in a way that might not require new bodies just to rename refinements (though as mentioned, that's not necessarily all these particular wrappers will do.)
This reverses the decision to allow a plain assignment via set-word to accept UNSET!. The reasonings motivating the feature were valid, but it can be done a better way, as pointed out by @earl and implemented in CHECK-UNSET. As a result, this restores locality of errors in bad assignments... again requiring those places where an unset should unset in an assign to explicit use of the SET/OPT operation (formerly SET/ANY)
|
Fantastic. Thanks for the quick turn-around! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a set of changes rolled up that were triggered by the idea from
@earl to make an operation designed to "set-and-test" a variable, which
came off as notationally pleasing without having to sacrifice the error
on plain get word assignments of unsets.
It makes the core operation where a value is optional named SET/OPT
and GET/OPT, which is just as short as GET/ANY and SET/ANY but more
in line with the present intentions for the connection between the unset
state and optional parameters and values. The /ANY variations are
moved into user code for reasons that they were likely going to have to be
anyway...which will slow the primitives down some in the near term but
there should be ways of addressing it if it becomes a problem.
Due to hedging as a result of thoughts in chat, a previous decision to name
the opposite operation of UNSET? as SET? is revoked...before any more
cases of it get created. It is not certain that this is the best use of the word,
or if it should be used at all, so the more conservative ANY-VALUE? was
chosen to match the existing typeset (which is still containing unsets for the
moment but about to change).