Are templated string embedded expressions "method parameters" or "lambdas"?

[John Rose]

On Oct 29, 2021, at 7:10 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Given that an unprocessed templated string involves at least some deferred evaluation, should we frame templated string parameters as being more like method parameters (all parameters evaluated eagerly, left to right), or should we treat them as lambda expressions, which may capture (effectively final) variables from the environment, and evaluate the full parameters expressions when they are needed?  

If we take away that given, that deferred evaluation is
“baked into” S.T., we are left (at least, I hope we will be
left) with no natural constraints on expressions, just the
usual practical ones.

It would be comforting to me if I found that, in the end,
all the “hole arguments” to S.T.’s are nothing more or less
than garden-variety method arguments, with no special
processing and no special restrictions.

It is natural to want to forestall “bad form” uses of a new
feature, and make parsing easier, and make it harder to
write puzzlers, and all the rest.  But there is a limit to
such things, and eventually you have to let the user
decide whether mis-use the language, according to
the tastes of its designers.

In any case, my design heuristics prefer few or no
limitations on what can “go in the hole”, just as there
are now few or no limitations on what can be passed
as a method argument.  Anything more restrictive
feels like the Language Nannies have arrived.

(Also, when I *do* use a Nanny, I prefer it to be wired
into the IDE, not the language.)

— John