With the arrival of COMMA!, the heavier vertical bar goes back to its sole entrenched purpose as an alternate in PARSE rules.
But this makes one wonder what it might be used for. A long time ago when it was still a separate BAR! datatype, the barrier was tried out as a newline in PRINT.
>> print ["sum one:" 10 + 20 | "sum two:" 3 + 4]
sum one: 30
sum two: 7
The reason this was panned was that separating expressions was a distinct intention. What if the strings were coming from an expression:
>> sum-label: func [n] [either n = 1 ["one"] ["two"]]
>> print [sum-label 1 10 + 20 | sum-label 2 3 + 4]
sum one: 30
sum two: 7
It could be interesting to people to separate sum-label 1 | 10 + 20 to make the expression boundary clearer. But if they got a newline in the process, that would not be good.
But now with COMMA!, we can reconsider:
>> print [sum-label 1, 10 + 20 | sum-label 2, 3 + 4]
sum one: 30
sum two: 7
You have your expression separations, and you have your newline.
Contentious With Other Definitions of |
I wouldn't propose accomplishing this by defining | to be the newline character in general.
It would be a keyword in DELIMIT (hence the SPACED that PRINT is based on).
This has the potential for causing confusion for anyone who redefines | and thinks they can use it freely. We run into questions of how to subvert PRINT's meaning it has chosen and invoke the operator.
But those tools are starting to emerge. reeval :| can trigger identical behavior to using a function in |... now even allowing it to be invisible. That doesn't cover enfix, but you get that with ->-
Note: I'm wondering now if
>-should be a "SHOVE" that doesn't give any argument to the right hand side, while->-pulls something from the left. That means you could say>- keywordto get generalized dialect subversion when something like PRINT has taken a keyword. As long as it doesn't take>-, that is!
I Think These Questions Are THE POINT
If we don't approach the mechanisms and understandings that allow things like PRINT to work this way, the whole exercise of building this framework is probably wasted work.
We need to know how to make dialect keywords, how to easily write dialects, and have patterns for mixing code that may collide with the dialect's choices.