It's getting quite close to the moment to cook up some new bootstrap executables and get the continuous integration back online.
The start of the derailment was the need to cease making {...} a string in the bootstrap sources, and support the new -{...}- or --{...}-- etc. format.
I've remarked on how this has been a surprisingly pleasant change. It not only has a "cut along dotted line" character, but it also means you can worry less about escaping your braces inside of these strings. That's especially important for things like JavaScript natives whose bodies are strings of JavaScript code... but it helps with headers too.
Rebol [
Title: "Your module title here"
Type: module
Name: your-module
Rights: --{
Copyright 2012 REBOL Technologies
Copyright 2017-2024 Ren-C Open Source Contributors
}--
License: --{
Licensed under the Apache License, Version 2.0
See: http://www.apache.org/licenses/LICENSE-2.0
}--
Description: --{
It almost feels like "cut along dotted line".
I'm surprisingly liking it.
Defaulting to this makes it easy to stick in mentions
of the }- construct used in code, without having to go
touch up your delimiters when you introduce it.
}--
]
I definitely do prefer the asymmetric delimiters to trying to do this with double quotes.
Rebol [
Title: "Your module title here"
Type: module
Name: your-module
Rights: --"
Copyright 2012 REBOL Technologies
Copyright 2017-2024 Ren-C Open Source Contributors
"--
License: --"
Licensed under the Apache License, Version 2.0
See: http://www.apache.org/licenses/LICENSE-2.0
"--
Description: --"
This doesn't work for me.
I almost dislike it enough to disallow it, so I don't
have to see code that does this.
"--
]
I think what I don't like about this is that it's like little darts pointing outward without really making a suggestion of grouping the inward things. It lacks cohesion.
BUT Nagging Question... Why --{...}-- and not --[...]-- ?
It crossed my mind to propose the idea of -(...)- etc. being interpolated strings.
>> num: 1000
>> print -(I'm an interpolated (num + 20), string)-
I'm an interpolated 1020, string.
It seemed interesting to me that the delimiters being "group-like" gave a hint that some evaluation would be going on.
But that gives rise to another thought... might --[...]-- being "block-like" give a hint of no evaluation?
e.g. there's nothing FENCE!-like going on here. The data is just inert. What if we leveraged brackets as the inert string type?
Rebol [
Title: "Your module title here"
Type: module
Name: your-module
Rights: --[
Copyright 2012 REBOL Technologies
Copyright 2017-2024 Ren-C Open Source Contributors
]--
License: --[
Licensed under the Apache License, Version 2.0
See: http://www.apache.org/licenses/LICENSE-2.0
]--
Description: --[
Here we have another conception.
It's more angular, doesn't need shift to enter it.
Doesn't it look a bit cleaner?
And it's all still just as easy to stick in mentions of
the ] or ]- construct used in code, without having to go
touch up your delimiters when you introduce it.
]--
]
--[o]--
In today's climate, of course we can see this as being more contentious with blocks... since they're much more common than FENCE!s. It may seem like a whole lot of brackets:
[--[this "is" a string]-- 1020 -[this too, how "bad" is this?]-]
However, do consider that as usage of FENCE! grows, there'd be contention there too. Also, syntax highlighting can help here for the not-completely-Amish cases.
I Only Just Thought This, But It Seems Good To Me
Note that my impressions and opinions are formed from having lived with --{...}-- for a while. Being a day-to-day user changed my views from initial reluctance to happy acceptance.
And this looks even better to my thusly trained eyes. 
It does mean that things like JS-NATIVEs won't have things that look "as much like" their natural delimiters:
quadrupler: js-native [num [integer!]] --[
let num = reb.UnboxInteger("num * 2")
return reb.Integer(num * 2)
]--
But really, were --{ and }-- pulling all that much weight here just because they had a brace?
quadrupler: js-native [num [integer!]] --{
let num = reb.UnboxInteger("num * 2")
return reb.Integer(num * 2)
}--
I'm not seeing it. The brackets feel cleaner, in part just because brackets are always cleaner.
And maybe this will help transition brackets over to braces for notations for construction-syntax types of things, to be more closely correlated with MAKE-ing things?
Anyone still paying attention have feedback here?
