Something Rebol touts as a big advantage is that it hasn't pinned a meaning to any words, so you can use them to mean what you want.
But I frequently have stressed over this, because words have associated costs that are non-trivial.
Example: The Section Divider: ===
I thought it would be neat if we could use this to have a Markdown-Like split of headers which just used plain words:
all [
=== STEP WITH JUST WORDS ===
step1 arg1
=== {STEP WITH STRING, NOT AS PLEASING} ===
step2 arg2
]
then [
print "=== is invisible, so it doesn't interfere with things like ALL!"
]
The idea is that it could be hooked in ways a comment couldn't...to print out messages to know you've reached the step (for instance).
Because I thought it was more pleasing, I designed it to permit words. === was as a variadic function which would keep looking across its input until it found a === to terminate.
(Note: Wanting to reclaim == for using as an even briefer way of saying "section" is one of several motivators for cleaning up the use of it for equality)
But there are issues that come up from trying to write strings without string delimiters in Redbol.
You have to write LOAD-able syntax. Having COMMA! makes it a bit more tolerable, but you can still get in trouble with unusual uses of other characters.
=== Here's a 3rd example; broken! ===
That's going to not be able to handle 3rd
in the current system (though the PACK! proposal could help here). Then the semicolon will wind out commenting stuff out.
Meaning of GROUP! is contentious. I use a lot of parentheses when I write text, and not mean running code. But we presumably want a way to get expressions in there:
That might not be a problem if we limit that to GET-GROUP!.
=== DEMO OF VARIATIONS (GROUP EXAMPLE) ===
count-up n 100 [
=== Running Step :(n) ===
print "This might be a way of doing it?"
]
Another alternative could be to use blocks for any evaluated portions, since square brackets don't often come up in English writing.
Plenty of Other Questions... I don't want to tackle them all here, because I'd like to move to the big issue.
Biggest Issue: Creating Tons Of Stray Bindings
On the happy side, with LET we are moving into an idea of dynamism in binding so that using a SET-WORD! doesn't get you a local. That keeps this from throwing in a local definition of PARSE:
foo: function [data] [
=== BEGIN PARSE: It would suck if this overwrote PARSE! ===
parse data [...] ; if PARSE: was gathered as local, parse would be unset
]
Things like this are why I was so adamant against locals gathering. It's good that it's gone from standard use, and relegated to being a weird feature for code golfing. LET may be slow right now, but better to be slow than absolutely wrong. Slow features can be sped up. Wrong features can only be deleted.
The storage and loading of words themselves is actually pretty efficient. The system is geared around it. I'm not terribly concerned about the storage overhead difference between strings and a bunch of words.
What's more troubling is all the bindings made in the user context. These words don't know their binding isn't going to be used. So the user context gets expanded and expanded.
I won't rewrite the explanation of this here. But see The Real Story About User and Lib Contexts
I Think Supporting Words This Way Is Mission Critical
There are a lot of kneejerk responses which would dislike === in the form that I suggest.
Some people wouldn't like that it's variadic. They might believe the principle of Rebol is based on blocks...so variadic functions shouldn't even be in the language to begin with. I think they're wrong, and we now depend on variadicness quite a lot.
Others might worry about the overhead caused by bloating up the symbol space...or the length of the code block. Or the CPU cycles consumed by having to run a variadic loop across the content of the line...one value at a time.
But I think my leaning is that being able to choose to work this way is the distinguishing factor of the language.
You can still use === {Text} ===
if you really want to. Or you can avoid using === altogether and just use a comment like ;===
or ;;
and it won't have any runtime aspects at all...though then you won't get a log when it reaches that line if you want it.
Using bash is making me realize that even as light as Rebol can be a lot of the time, it's still too heavy sometimes. Having to put things in quotes adds up 2 characters at a time, over time. We should keep an eye on bending the mechanics to make it possible to use LOAD-ed "Rebol sentences" literally, and find places where that makes sense.
This Means Binding Has To Be Rethought... More...
We're just pinning down more of the requirements. So as those requirements get locked, then hopefully that will make a design "emerge".