COMPOSE of ANY-STRING! in XXX-GROUP!: feature or misfeature?

I'm rather fond of what the new fancy COMPOSE is able to do with the SET-GROUP!, GET-GROUP!, and "LIT-GROUP!":

 >> compose [
     (second [a b c]): @(second [[a b] [c d] [e f])
 ]
 == [b: @[c d]]

This is all kinds of convenient, but I wondered if it should be necessary to convert things to WORD! if they were strings:

>> n: 1
>> compose [(as word! unspaced ["var-" n]): (n)]
== [var-1: 1]

If the word is just going to be unbound anyway, couldn't you just say that's what happens to strings?

>> n: 304
>> compose [(unspaced ["var-" n]): (n)]
== [var-304: 304]

It seemed cool though it made me a little uneasy. But the thing that makes it uneasy is the asymmetry with plain GROUP!:

>> n: 304
>> compose [(unspaced ["var-" n]): (unspaced ["var-" n])]
== [var-304: "var-304"]

This feels like a bit of a bug waiting to happen...where you're getting the automatic conversions sometimes but not others. But a parallel problem exists if you accept GET-WORD!/etc. in these slots:

>> compose [(second [:a :b :c]): (second [:a :b :c)]
== [b: :b]

The plain groups are verbatim...there's no COMPOSE syntax for "plainify this". Which makes them break the pattern.

Yet it's a rather useful feature to do these transformations. Do we just trust that people who use the feature will understand it, and not deprive them of the convenience?

1 Like

There's not really a way to know until this gets into the hands of more people. You'll possibly be letting dim-bulb devs shoot themselves in the foot, but clever devs to do cool things in an impressively concise way.
So while it's slightly trickier to learn, with more line noise, it'll save multiple lines of code each time you use it-- which I think on net will be very gratifying.

1 Like

Well as a data point, one particular dim bulb made the very mistake when editing this test, blindly changing all the (to word! ...) to not include the conversion. Since that dim bulb is me, I bring it up. :bulb:

In the interests of time, I feel like when we hit things like this, we should be conservative. It's not like converting to a word manually isn't going to be backwards compatible if someday this is deemed a good idea. I think my decision-making plan is to hold off on this kind of thing until there's more review.

1 Like