ENVELOP (and COMPOSE!) By Example

[hostilefork]

So I went ahead and did the transition to arity-2 COMPOSE, so I could see the effects.

Since bootstrap needs to still work, I needed to have a name for the arity-1 version, and I called it compose1 Which actually isn't a terrible name for the arity-1 version. Maybe compose-1 would separate the e and the 1 a little better, but it also adds noise.

There's also the possibility of compose*, though adding a star usually means "lower level version". But more generally it could be argued that it's a "special version".

What its doing is actually:

compose1 list
=>
compose (inside list '()) list

So maybe calling it compose-inside would be more informative, but that wouldn't tell you that you were using groups, so it's compose-groups-inside...

@hostilefork

Stealing the binding from the tip of the block you're composing and using that in the slots is a kind of "weird backchannel". If that's what you're doing, you're the weird one, so maybe your code should reflect that.

Well, when I put it that way, COMPOSE* might be good for this.

Anyway, I think the competition is between calling it COMPOSE* or COMPOSE1

If we had CHAIN! dialecting, it might permit:

>> compose [a (1 + 2) b]
== [a 3 b]

>> compose:${{}} [(a) {{1 + 2}} {b}]
== [(a) 3 {b}]

But that feature is very speculative, and binding issues may make it non-feasible.

@hostilefork

But, It Would Drive The "Noise" Level Higher...

Some (like @rgchris) do not like symbols in code at all.

Having COMPOSE frequently instantiated as compose $() [...] would be a thorn. (Though as I've stated, I think you really should be doing compose $() '[...] much more than one would think).

This is a pretty tough call, but I think I'm on the side of saying that COMPOSE should be arity-2.

Beyond the necessity of providing a binding environment when you want to apply COMPOSE to strings, I'm seeing too many places where an arity-1 COMPOSE can't do what you want.

I also feel like taking away the assumption of COMPOSE being groups is good--it's not groups, it's the pattern you choose. I like {{...}} because at least now, that has no meaning and stands out a lot better.

The harsh reality is that to really make things work... binding has to be thrust into the awareness of those who are building and composing code.

Being able to evaluate templated code groups (or blocks, or fences...) in an environment that is different than the environment of the surrounding code is not something that has been easy before.

But I think it's foundational--and as I've said, the most common surrounding context is likely no context... with the intention of inheriting the meaning from wherever you are putting the composed code.