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

[Tagir Valeev]

+1 to Guy and John

With best regards,
Tagir Valeev

On Sun, Oct 31, 2021 at 4:44 AM John Rose <john.r.rose at oracle.com> wrote:
>
> Brian will not be surprised to hear that I agree with Guy here.
>
> The Logger use case is the main one, IIUC, which is driving
> the insertion of pass-by-name (automatic quoting as if by ()->)
> into the current ST design.
>
> If we want something like Log.note("foo = "+foo()) to auto-quote to
> Log.note(() -> "foo = "+foo()) we should do it as its own avowed
> language feature (akin to auto boxing and varargs) and not hide
> it inside of string templates.
>
> (Turning x to ()->x is indeed a kind of quoting, since it allows the
> user access to a useful name of x without elaborating x.
> If and when we add lambda cracking it will also become a way
> to literally quote expression trees.  If the term auto-quoting
> is off the mark, may I suggest auto-delaying or pass-by-name.)
>
> I would be delighted if we could define string templates without
> rolling in an auto-delay feature for their arguments, then later
> add auto-delay of arguments (to arbitrary methods) as a proper
> language feature, and then, triumphantly, cross-apply those
> two features to create Logger APIs that (a) make great use of
> STs, and (b) smoothly delay their operands until the Logger
> has decided it really wants them.
>
> On Oct 30, 2021, at 2:11 PM, Guy Steele <guy.steele at oracle.com> wrote:
>
>
> On Oct 30, 2021, at 1:04 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
> I think that deferred semantics could be confusing and it provides too
> little benefit to justify its use.  . . .
>
>
> I'd characterize these argument as "this deferral is too magic and raises too many questions for too little benefit; if you want deferral, do it explicitly with ->.
>
>
> I will go a step further: the proposed deferral semantics is too _surprising_.
>
> Joe Programmer will look at
>
> FOO."I have \{n+1} apples in my basket and \{c.size()} elements in my collection."
>
> and fully expect that the expressions `n+1` and `c.size()` will be evaluated right away, before any of the magic associated with that dot happens.
>
> There are languages for which deferred evaluation is the norm, the expected way of doing things. Haskell is one of them. Java is NOT one of them.
>
> Java now has a standard strategy for user-specified deferred evaluation: ->.  So it would also be surprising to introduce another, unrelated mechanism for user-specified deferred evaluation without a REALLY compelling reason. (I say “user-specified” because there are certain other mechanisms that are built-in, such as the ? : operator and statements such as `if` and `while`.)
>
> Joe Programmer would expect that if FOO wants to provide for deferred evaluation, it would do so by accepting lambdas, and Joe would expect to provide them.
>
> —Guy
>
>