TAG! - COMPOSE is IT (tag-specific composition)


There's a new mechanism now for escaping GROUP!s in your code that you want preserved during a COMPOSE. Just use an apostrophe:

 >> compose [(1 + 2) '(1 + 2) ''(1 + 2)]
 == [3 (1 + 2) '(1 + 2)]

If you're doing more substitutions than not, you may appreciate being able to mark the occasional GROUP! with the backslash as a "do not compose" indicator.

But one of the good things about templating is to be able to write most of your code normally, and then point out just the parts you want to substitute. So if you're using so many groups that just being in a GROUP! isn't distinguishing what you want to substitute, tagged COMPOSE to the rescue:

>> compose <*> [(1 + 2) (<*> 1 + 2) (1 + 2)]
== [(1 + 2) 3 (1 + 2)]

The TAG! has to be given literally between the COMPOSE and the expression you want to compose. (This is a requirement for <skip>-ability. But you can pick any tag you like. Currently it is matched case-sensitively.

Doubled-groups still have /ONLY semantics:

 >> x: [a b c]

 >> compose <$> [(1 + 2) (<$> reverse copy x) ((<$> reverse copy x)) ((1 + 2))]
 == [(1 + 2) c b a [c b a] ((1 + 2))]

You don't have to use symbols...any tag will do. Could be a whole word with meaningful names, which might be valuable if you were doing it in several steps...where earlier phases could leave tags for later phases to compose. You might also tag with numbers, <1> <2>...

For now this is limited to just TAG!. It could be other inert types (like ISSUE! or TEXT!) but there doesn't seem to be a great reason to encourage that.

Facing the facts: SWITCH must evaluate clauses
Taking BLANK!-headed PATH!s Out-Of-Band

Very useful!
Maybe also the FILE! type could be enabled:

compose % [(1 + 2) (% 1 + 2)] ...


An alternate outcome for this could be:

== [3 '3 ''3]

And given the existence of the TAG!-based composition if you need it, I'm wondering if that might actually be preferable for COMPOSE. Generic escaping of this nature is more useful than it might look--for reasons that you don't really appreciate until you start doing "hard things".

And as I mention, one of the nice things about working in a "template" style is having the things you intend to look as they will in the output be "as-is". The peel-one-escape-level-off is a bit of a curveball, and tagged compose seems to achieve the goal without that curve.

(and also, welcome @LkpPo ... and feel free to chime in on any post you like, here or on SO chat)!


Hello @hostilefork,

I will read and like. I tried to reply on a topic about SWITCH, but it's locked or I can't post with a newbie profil on the forum.

I'm read time to time the trello board. I appreciate what you did for a better rebol.

I have not yet founded the time to learn Rebol. I tried but not have the whoa flash yet.

Maybe it's because Rebol is very different.

On the roadmap, for useful programs, I thinks UTF-8 is really important.


I'm not the forum administrator, and he seems to be gone on holiday, but I can ask about it when he gets back.

Thanks! It is a work in progress. Not every change has turned out to be good, but many have. I'm not afraid to update it if a better idea is found--or even just go back to how it was.

Me too. And if you look at the popularity of encodings UTF-8 seems to have already won. If you are trying to build a simple system, it seems one that didn't need to support anything other than UTF-8 internally would be the future. This is believed by The UTF-8 Everywhere Manifesto.

I will try and sync up the branch that only uses UTF-8... it had some success early in the year:

If you can, please join StackOverflow and ask a question or two. We can upvote you and you can join the chat. It's a unique experience--I think--to be able to come and be a big part of the design of something novel. And possible for someone to make a big impact, if they wanted to!


Ok, I will join SO in some days.

I thinks Utf-8 only is probably the future of encoding. The convergent movement of Windows and Linux Subsystem will erode the last bastions.