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

[John Rose]

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<mailto:guy.steele at oracle.com>> wrote:


On Oct 30, 2021, at 1:04 PM, Brian Goetz <brian.goetz at oracle.com<mailto: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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20211030/0fc4660e/attachment.htm>