Due to Rebol's run-on-sentence aesthetic, I've always thought it needed some way to punctuate that was both visually lighter than grouping, and that by not using groups wouldn't interfere with COMPOSE.
Some people would be content to just use spaces:
any [even? x match [block! group!] y foo baz bar]
On the downsides of that, it doesn't have any "teeth", e.g y might take
foo as an argument. It's also lost in any MOLD operation as the specifics of spacing is not preserved.
The vertical bar has been in place for a while, which I liked for its barrier-ness and even looking weight:
any [even? x | match [block! group!] y | foo baz bar]
But PARSE was immovably attached to its usage for alternates. Looking at PARSE lately and trying to make sense of it, I really feel like it needs this just as much as ordinary code.
Period was another option that was looked at:
any [even? x . match [block! group!] y . foo baz bar]
And by now everything has been considered...backslashes:
any [even? x \ match [block! group!] y \ foo baz bar]
any [even? x .. match [block! group!] y .. foo baz bar]
Having BLANK! itself act as a barrier as opposed to something that can be taken directly as an argument to a function:
any [even? x _ match [block! group!] y _ foo baz bar]
Strange ideas like a COMMA! type that renders glued to the thing to its left, even though it's an independent element:
any [even? x, match [block! group!] y, foo baz bar]
In a parallel universe where semicolons weren't taken for comments, perhaps they'd be considered:
any [even? x; match [block! group!] y; foo baz bar]
...although that looks a bit too much like SET-WORD!s, there. Which is yet another argument for why abc; is now rightfully illegal as a WORD!.
Should We Lower the BAR?
There's a lot of mechanism to support barriers and invisibility, and it's something you can use generically...so the facilities that started out as a distinct "BAR!" datatype have grown into a whole lot of power that you can apply to any function.
But I have to admit I don't feel as attached to the vertical bar for separating expressions as I did some years ago.
- Can't use it in PARSE because | is pretty much set as rule alternate
- It seems too heavy for what it's doing.
- Might be useful for a pipe operator or other ideas in plain dialecting (noticed "Arturo" used it for that)
While I might have rejected a simple dot as "too slight" in the past, I may now feel that the subtlety is favorable. And the COMMA! idea is actually looking pretty good--if you just imagine that being a datatype that behaves exactly as expression barriers do today:
>> length of [1,] == 2 >> type of second [1,] == @[comma] >> 1 + 2, == 3 >> 1 +, 2 ** Script Error: comma encountered while fulfilling argument ** Near: [1 +, ~~ 2]
You Could Still Make BAR! or Whatever You Want
The current mechanisms would work, and I think I'm going to make sure they work for . too.
(I'll need to figure out how to let you make any UTF-8 symbol you want act like an expression barrier in PARSE. But let's say I figure out how.)
Is COMMA! worth a shot? Does period look better or worse to your tastes?
Important to bear in mind is that on the table is now the idea that accessing things which you want to say aren't calling functions would be done with a terminal period. This could risk creating things like:
any [even? x., match [block! group!] y., foo baz bar]
Compared to letting lone periods act as barriers:
any [even? x. . match [block! group!] y. . foo baz bar]
Compared to status quo of today's barriers:
any [even? x. | match [block! group!] y. | foo baz bar]
Compared to selective grouping:
any [(even? x.) (match [block! group!] y.) foo baz bar]
(Note that in PARSE, the "grouping" is actually "blocking"...which looks even heavier)
Oddly enough, I don't think the commas do all that badly even in this pathological case. And as I show with the groups, it's not like you have to use the comma if you don't feel the code "looks right".
Anyway--remember that the goal is that you can twist up the language even for the span of a function. So while running that function if you decide you want | to be a barrier but not for the rest of your program, you can do that!