Closed hostilefork closed 2 years ago
This happens because the state used to convey END is "endish nulled", which looks to the type checking like a plain NULL.
The goal has been to be able to tell the difference between reaching the actual end, and being passed a ~void~ isotope. It may make more sense to bend the rule that BAD-WORD! isotopes aren't legal in parameters and pass in a ~void~ isotope in these cases...which would not be legal for a normal parameter typically.
Handling of END needs review as a concept. The idea that normal parameters treat it as NULL is interesting, but META parameters are breaking the rules by using a BAD-WORD! isotope of ~void~. Perhaps it could be something else, like BLANK! for meta parameters?
Handling of END needs review as a concept. The idea that normal parameters treat it as NULL is interesting, but META parameters are breaking the rules by using a BAD-WORD! isotope of
~void~
.
The redesign verdict on this is that ~void~
isotopes are so reactive that they actually vanish.
https://forum.rebol.info/t/pure-vs-impure-invisibility-do-we-need-both/1782/2
This means that a ~void~ in a ^META parameter can be reserved for the case of actual invisibility--e.g. a completely missing parameter (which we can interpret as an END, because if it wasn't an END then some other value would have slid in to take the place). That cleans up the wart where pure invisibility was being represented by a ~void~ isotope in ^META arguments.
Moving checking for end into the parameter fulfillment and no longer part of the "type checking" of a frame solves the problem in this issue.
https://github.com/metaeducation/ren-c/commit/0bb71c81fc7dbacb3dcc454d959cafedaf52e950
Is missing /DUP count, this should be an error (instead of revoking the refinement as NULL)