While messing around with some experimental debugger code, I made BREAKPOINT an invisible that doesn't take any parameters. This means you can write foo + breakpoint bar. It would break after foo evaluates as the first argument to +, before bar evaluates as the second arg to +.
But should you be able to say foo + (breakpoint) bar ?
The idea that a GROUP! could simply vaporize away if its contents are empty or invisible seems a bit unsettling. So these cases were errors:
>> 1 + () 2 ** Error: + is missing its value2 argument >> 1 + (comment "Hi") 2 ** Error: + is missing its value2 argument
But how unsettling would it really be if those worked?
>> 1 + () 2 == 3 >> 1 + (comment "Hi") 2 == 3
I had said this was too weird to be justified "just for some comments". But when you think about a interesting multi-parameter breakpoint, wouldn't it be nice to put it where you want it and group it as well?
foo + (my-complex-breakpoint #arg1 #arg2) bar
You wouldn't be able to do this if grouping forced the production of a ~none~ isotope out of that emptiness. The same would be true for using DUMP today:
foo + (-- x y z) bar
As invisibles become more an integral part of the system, it no longer seems like being weird for the sake of being weird.
Permissive Invisible Groups
An argument for groups not vaporizing is if you think of
(...) as being a synonym for
do [...]. If your code is coming from an unknown source, and it's a GROUP!...you may not know if it's going to vaporize or not. But...
...is that the actual scenario for GROUP!s? How often are unknown code bits being passed around as GROUP!, and then executed by being spliced into evaluation? Aren't blocks the currency for that?
why not just use DO on your groups if you're worried? If you do not know what kind of code is in a GROUP!, it must be coming by way of a variable. So the way you are getting the evaluator to run it is either DO (where this isn't an issue, because empty groups return void) or you've made an effort to splice it into a block so it evaluates inline. If you're forced to splice, why not splice compose [... do '(my-group) ...] if you don't want the ability to vaporize? It's a short word, and it liberates GROUP! to a distinct novel usage and behavior.
Of course, it's a thing you'd have to learn about GROUP!... that they aren't a synonym for DO of a BLOCK!. But it's a nuance... groups just group things, they don't synthesize any VOID!s or artificial values of their own.
The nuance is pleasing, and simple. I found that I had a preference for:
case [ something [...] (elide print "Got this far") something-else [...] ]
...as opposed to:
case [ something [...] elide (print "Got this far") something-else [...] ]
(Though technically you don't really need a GROUP! at all in that case, but the use of groups is often a subjective thing.)
And if there isn't permissive group invisibility you won't get it any other way. I feel like there's multiple points in favor of this... expressivity, and a coherent story: "groups only function is to group things, they are ghostly,
() 1 + () (comment "hi") 2 () is 3"
(Note: Because the GROUP!s are not enfix functions themselves, they are not entirely ghostly...they are "only as invisible as non-enfix invisibles are". This is to say that
1 () + 2 can't be the same as
1 + 2, because, the 1 doesn't see the + through the group!. It can't start evaluating it either to find out if it's empty and then have to back out of that...so this is an error.)
(Also worth pointing out: if you COMPOSE a GROUP! which has null or splice an empty block via group...not even -invisible-, you get it vaporizing:
compose [1 + (if false [<not-spliced>]) 2] => [1 + 2])