I remembered while writing this that you have to put branches in GROUP!s, because branches are "soft-quoted" slots (or, more accurately "soft literal") slots.
The reason you don't have to put the -> form in groups when you use them as branches is because there's deference to a leftward-literal operation in a soft-literal slot. The left literal beats the right literal.
But this has a cost: you're paying to generate the function whether it gets called or not.
Historical Rebol has this problem anywhere functions are passed as handlers. Consider TRY/EXCEPT in R3-Alpha:
r3-alpha>> try/except [1 / 0] func [e] [print ["Error Handler:" form e/id]]
Error Handler: zero-divide
Putting it in a GROUP! won't help there, because /EXCEPT doesn't suppress any evaluation from that GROUP!. But in Ren-C, branches are literal, so the groups can be used to suppress the evaluation unless the branch runs.
Is Making Uncalled (Unpacking-) Lambdas A Problem?
That depends...
-
does an unpacking lambda make a deep copy of the block?
-
or does it just make a small structure that pairs the name of the parameter(s) with the body of code?
Today's it's [2]... -> just makes that small structure (while LAMBDA makes the full copy). But this means you get the semantics of a non-copying construct:
>> block: [print ["Hello" x]]
>> one: x -> block
>> append block spread [print ["Goodbye" x]]
>> two: x -> block
>> one 1020
Hello 1020
Goodbye 1020
>> two 1020
Hello 1020
Goodbye 1020
So you would have to say x -> copy/deep block to get a unique copy of the body.
Beyond the semantic implications of not copying, there's a performance implication if you call it more than once... because the preparations that make the body a little faster to call that happen during the copy are not done.
There are some other options like going in some strange "branch dialected" direction, and say that BLOCK!s with a certain format were "parameterized", moving the parameter name into the block somehow, not necessarily this but like this:
y: case [
1 > 2 [<no>]
1 < 2 [<yes>]
] then [x ->
assert [x = <yes>]
1000 + 20
]
I'd rather put every parameterized branch in a group than do that.
y: case [
1 > 2 [<no>]
1 < 2 [<yes>]
] then (x -> [
assert [x = <yes>]
1000 + 20
])
But still, no. It's much better to push on optimizations of the stylized function generation so that it's cheap as can be to make regardless of the branch being taken, it's the source we want to write:
y: case [
1 > 2 [<no>]
1 < 2 [<yes>]
] then x -> [
assert [x = <yes>]
1000 + 20
]
Just another devil in the details to worry over. But wanted to write up a reminder of why plain LAMBDA has to be in a GROUP! if you're going to use it in a branch, because I'd forgotten you had to do that.