The Superpowers of Ren-C's Revamped COMPOSE

Usage Feature Discover
1

COMPOSE is one of Rebol's most useful and recognizable constructs. As with most-things-Ren-C, it has evolved to become far more powerful.

No Splicing By Default, GROUP! Antiforms Request Splicing

One of the immediately noticeable differences is that there is no /ONLY option any longer. A plain BLOCK! will not splice its evaluative result. So if block: [a b c], it is different from historical Redbol:

rebol2/r3-alpha/red>> compose [value: (block)]
== [value: a b c]

ren-c>> compose [value: (block)]
== [value: [a b c]]

If you want to have something splice, you do this with GROUP! isotopes. For instance, SPREAD produces them:

ren-c>> compose [value: (block), (spread block)]
== [value: [a b c], a b c]

  • You can mix and match splicing parts and non-splicing parts in the same COMPOSE!

  • It gets rid of an instance of /ONLY, which has always been something that causes head-scratching to new users ("only what?")

I am convinced that practice has shown that not splicing is a safer and more intuitive default. You're so often dealing with composing several values at a time that the odds of you knowing precisely what data type all of them are become lesser. There's no question this is the better behavior for people who are writing and reading the code.

The (...) Slots will Vaporize Voids!

In my list of "non-negotiables", I've always said this had to be true, somehow:

>> compose [<a> (if false [<b>]) <c>]
== [<a> <c>]

For quite some time, a conditional like IF that didn't run its branch would return NULL. Because NULL couldn't be put in a block, it seemed like it was a good fit for signaling vaporization of a clause in a COMPOSE. But I was nervous because as NULL came to mean "soft failure", this felt like you could be sweeping a failure under the rug.

But with isotopes, we got a menagerie of states that couldn't be put in blocks (and VOID, with its own antiform). So when un-taken IF provides another choice of VOID vs. NULL, it provided the best of both worlds, where NULL can give a specific error tied to null splicing.

>> compose [<a> (select [a 10 b 20] 'c) <c>]
** Script Error: non-NULL value required (see MAYBE, TRY, REIFY)

>> compose [<a> (maybe select [a 10 b 20] 'c) <c>]
== [<a> <c>]

>> compose [<a> (? select [a 10 b 20] 'c) <c>]  ; shorthand for MAYBE
== [<a> <c>]

That specific error can be used to interesting effects, see CURTAIL

Decorated Groups (including quoted) Apply Their Decorations!

Ren-C has a lot of variations of GROUP!:

COMPOSE does useful magic for you, and if the type a GROUP! evaluates to supports the decoration, it will be applied!

>> fruits: [apple banana]
>> dispositions: [favorite least-favorite]

>> compose [(dispositions.1): '@(second fruits)]
== [favorite: '@banana]

Once you have this, you won't want to go back. The premise of the language is being able to dynamically play with code and generate structures on the fly. This makes that feel extremely seamless.

Change the List Type(s) With COMPOSE2

What if you don't want to use parentheses to point out your compose slots, but brackets?

>> compose2 [] [(1 + 2) [1 + 2] (1 + 2)]
== [(1 + 2) 3 (1 + 2)]

Or what about doubled-parentheses, instead of just one pair?

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

How about you still want to use groups, but you want to mark them with there being a signal inside the group to show it's a substitution site?

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

Whoa!

Predicate Functions Can Process the Compose Slots!

We now have the ability to run functions on the groups before you splice them.

So if you want to define COMPOSE that acts historically like Rebol2 (splicing unless you say :ONLY), here's one way you can do it:

old-compose: adapt augment compose/ [:only] [
    if not only [
        predicate: func [group <local> product] [
            either any-array? product: eval group [spread product] [:product]
        ]
    ]
]

We added the :ONLY refinement, and if you don't use it then it adds a processing function for arrays. This gives you the historical result!

:surfing_man:

This only scratches the surface of what's possible, with these bendable and useful ergonomics.

2 Likes
2

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

compose2 '(%) [(1 + 2) (% 1 + 2)] ...

UPDATE: This feature wish has been granted (arbitrary patterns and list choices were added via COMPOSE2 after the original post, which has been edited for modern conventions).

2 Likes
4

3 posts were merged into an existing topic: LkpPo (Stéphane)

8

Scrumptious enhancements here! :tongue:
I've used COMPOSE quite a bit in my code previously and was grateful for it, but it was just a normal rebol way of getting things done. The labeling and predicate changes make it much more likely that I'll be building a lot more of my code with this powerful function.

1 Like
11

2 posts were split to a new topic: ((Doubled Groups)) as a Dialecting Tool

13

So it comes up sometimes that you want to mark the groups that you don't want to compose:

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

I'm not quite sure how to say this. It could be a refinement...

>> compose2:anti '(<!>) [(1 + 2) (<!> 1 + 2) (1 + 2) (1 + 2)]
== [3 (1 + 2) 3 3]

I don't like adding tons of refinements, and this is kind of a weird one semantically.

It would be nice if the pattern could encode it:

>> compose2 '(not <!>) [(1 + 2) (<!> 1 + 2) (1 + 2) (1 + 2)]
== [3 (1 + 2) 3 3]

This might have to assume that the inside pattern was ordinarily just one non-list thing allowed, so if you saw two things you know the first word is a dialected thing.

Maybe the more general thing is to allow the use of a PARSE rule to decide what to compose? COMPOSE2:PARSE?

Anyway, this "name the slots you don't want to compose and compose all the rest" is actually something I've had real uses for. So worth thinking about...

1 Like