metaeducation / ren-c

Library for embedding a Rebol interpreter into C codebases
GNU Lesser General Public License v3.0
128 stars 27 forks source link

END being tolerated when it shouldn't #1129

Closed hostilefork closed 2 years ago

hostilefork commented 3 years ago
>> collect [keep/line [a b c] keep/dup/line [d e f]]
== [
    a b c
    d e f
]

Is missing /DUP count, this should be an error (instead of revoking the refinement as NULL)

hostilefork commented 3 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?

hostilefork commented 2 years ago

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