END being tolerated when it shouldn't

[hostilefork]

>> 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]

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]

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.

0bb71c8