<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 22 Sep 2022, at 14:01, Alex Buckley wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">If a future Java platform allows the embedded expressions themselves to be represented at run time (e.g. via a dynamically-computed constant that denotes the AST seen at compile time),</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">Yes, that’s the essence of what I mean by “expression quoting”.</p>
<p dir="auto">(A complicating feature is that expressions can refer to local variables. The quoting mechanism must define whether and how these variables are “captured” in the AST-like constant. The comparison here with variable capture by lambdas is inescapable.)</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">then a template processor could choose to (re)evaluate an embedded expression in the current environment, no lambda "quoting" needed.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">Yes. There are many possible ways to signal that an expression has to be stored in some “transparently reprocessable” form, in the class file, and there are any number of ways to store such expressions in a classfile. (The basic bytecode sequences used today don’t cut it, since they are not self-delimiting, and cannot be recontextualized or destructured like an AST could be.)</p>
<p dir="auto">But: Almost any expression quoting facility I can imagine for Java is largely isomorphic with a lambda-based “quoting” feature, disregarding details of surface syntax. (The bytecode translation of a “crackable” lambda would include a bundle of AST associated with the lambda object.)</p>
<p dir="auto">Surface syntax itself is fungible: quote-eliding sugar can make quotes (such as the <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">()-></code> “operator”) disappear altogether from the source code, if we choose. Auto-quoting could be gated on logic similar to auto-boxing. Or not. (And whether or not lambdas are part of the story.)</p>
<p dir="auto">One disconnect from lambdas (per se) is that expressions like <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">a[i++]</code> can produce multiple results via side effects on local variables, which lambdas cannot manage directly. So quoting <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">a[i++]</code> is not just a matter of saying <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">()->a[i++]</code> with or without lambda cracking. But perhaps <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">a[i++]</code> could be modeled using pattern-based APIs which output multiple named bindings. And if pattern-deconstructor lambdas “were a thing” then once again <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">()->a[i++]</code> could be a candidate syntax, as well as its auto-quoted version <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">a[i++]</code> (contextually processed).</p>
<p dir="auto">To be clear: I’m not proposing anything here, just commenting on the larger design landscape as I see it. I’ve probably said more than enough for today’s purposes, but I do know people are thinking and dreaming about such things, based on discussions of lambda cracking at JVM Language Summits of old.</p>
</div></div></body>
</html>