2:25 PM, Remi Forax wrote:
*From: *"Brian Goetz"
*To: *"John Rose"
*Cc: *"amber-spec-experts"
*Sent: *Mardi 2 Novembre 2021 18:43:29
*Subject: *Translation musings (was: Are templated string embedded
expressions "method param
> From: "Brian Goetz"
> To: "John Rose"
> Cc: "amber-spec-experts"
> Sent: Mardi 2 Novembre 2021 18:43:29
> Subject: Translation musings (was: Are templated string embedded expressions
> "method parameters" or "lambdas"?)
&
I think we need to redirect a bit.
I’m pointing out a different proposition: *If* you need static
validation of a string, *then* you need something constant about the
receiver. By constant I mean, very specifically, “fixed no later than
just before the first execution of of the string templa
On Oct 31, 2021, at 8:52 AM, Brian Goetz
mailto:brian.go...@oracle.com>> wrote:
I suggest that, until we roll out more of the machinery
we intend to roll out, such as type classes, that we
restrict the operand x (the receiver LHS of the S.T.)
to be a statically constant expression.
I think this
On Nov 1, 2021, at 8:37 PM, John Rose
mailto:john.r.r...@oracle.com>> wrote:
In this case, the magic declaration “final var i = i” switches
(There are two bikeshed colors shown here; it is very simply
“final i” in the desugaring example. “final i” is very clearly
a super-narrow feature, another
On Oct 31, 2021, at 6:47 AM, Brian Goetz wrote:
>
>
>> This is a somewhat separate topic but I would be glad to see some
>> improvement here with respect to good old for loops, as I often saw
>> copying to a new variable for the sake of lambda capture inside the
>> loop.
>
> As a separate separ
On Oct 30, 2021, at 9:30 PM, Tagir Valeev
mailto:amae...@gmail.com>> wrote:
This is a somewhat separate topic but I would be glad to see some
improvement here with respect to good old for loops, as I often saw
copying to a new variable for the sake of lambda capture inside the
loop.
Like if a va
I suggest that, until we roll out more of the machinery
we intend to roll out, such as type classes, that we
restrict the operand x (the receiver LHS of the S.T.)
to be a statically constant expression.
I think this is taking it way too far.
*If* the receiver is a statically constant expres
> From: "John Rose"
> To: "Guy Steele"
> Cc: "Brian Goetz" , "Tagir Valeev"
> ,
> "Jim Laskey" , "amber-spec-experts"
>
> Sent: Dimanche 31 Octobre 2021 01:18:38
> Subject: Re: Are templated string embedded
This is a somewhat separate topic but I would be glad to see some
improvement here with respect to good old for loops, as I often saw
copying to a new variable for the sake of lambda capture inside the
loop.
As a separate separate topic, I'd like to make good-old-for-loops more
of a thing of
> > Finally, the inability to use non-effectively-final variables would be
> > very limiting. Note that the most classic way to iterate numbers in
> > Java is still for loop:
> >
> > for(int i=0; i >System.out.println("array[\{i}] = \{array[i]}");
> > }
> >
> > Inability to do this simple thing
+1 to Guy and John
With best regards,
Tagir Valeev
On Sun, Oct 31, 2021 at 4:44 AM John Rose 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 ()->
On Oct 30, 2021, at 3:22 PM, John Rose
mailto:john.r.r...@oracle.com>> wrote:
restrict the operand x (the receiver LHS of the S.T.)
to be a statically constant expression. If we do that,
then we can hand three things to a bootstrap method
that can do static validation:
1. the (constant) receive
On Oct 29, 2021, at 7:10 AM, Jim Laskey 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
Though I agree it's not a strong argument, but comment content is arbitrary.
It's either /* arbitrary characters */ or // arbitrary characters .
String content has to be contextual interpreted, i.e. have knowledge of valid
escape sequences or translation of eoln.
String s = """
\{"abc\"}"}
"""
On Oct 30, 2021, at 2:44 PM, John Rose
mailto:john.r.r...@oracle.com>> wrote:
its own avowed language feature
And, full disclosure, besides pass-by-name I see two other language
features that could be distinguished from the current design, whether
or not they ever appear separately (as I hope pa
And Brian will not be surprised to hear that I agree with John’s further
elaborations here.
If it can be done, it would be far preferable to have two separate, orthogonal,
general features that interact smoothly.
On Oct 30, 2021, at 5:44 PM, John Rose
mailto:john.r.r...@oracle.com>> wrote:
Br
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(() -
On Oct 29, 2021, at 10:10 AM, Jim Laskey
mailto:james.las...@oracle.com>> wrote:
For our early templated string prototypes, we restricted embedded expressions
to just basic accessors and basic arithmetic. The intent was to keep things
easy to read and to prevent side effects. Over time, we be
On Oct 30, 2021, at 1:04 PM, Brian Goetz
mailto:brian.go...@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
I think that deferred semantics could be confusing and it provides too
little benefit to justify its use. For example:
DebugLogger."The number of objects: \{counter.incrementAndGet()}";
We saw a number of bugs like this in assert statements. The unpleasant
thing is that in unit-tests assertio
Hello!
I think that deferred semantics could be confusing and it provides too
little benefit to justify its use. For example:
DebugLogger."The number of objects: \{counter.incrementAndGet()}";
We saw a number of bugs like this in assert statements. The unpleasant
thing is that in unit-tests asse
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Jim Laskey" , "amber-spec-experts"
>
> Sent: Vendredi 29 Octobre 2021 20:26:28
> Subject: Re: [External] : Re: Are templated string embedded expressions
&g
Do we really need to support the second case at all ?
Yes :)
Instead of
"Hello \{name()}"
it can be written to something like
() -> F."Hello \{name()}"
That deprives your callee of the opportunity to choose the formatter for
you. Whoops, now the feature is way less expressive. O
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax" , "Jim Laskey"
> Cc: "amber-spec-experts"
> Sent: Vendredi 29 Octobre 2021 19:20:20
> Subject: Re: Are templated string embedded expressions "method parameters&q
For me, "deferred execution" is not the right way to think about the
sub expressions of a templated string.
I think there really are two (related) cases here.
The first (and more common) case is when you provide a formatter object
directly:
Foo f = F."Hello \{name()}"
Here, there are
> From: "Jim Laskey"
> To: "amber-spec-experts"
> Sent: Vendredi 29 Octobre 2021 16:10:54
> Subject: Are templated string embedded expressions "method parameters" or
> "lambdas"?
> For our early templated string prototypes , we restricte
For our early templated string prototypes, we restricted embedded expressions
to just basic accessors and basic arithmetic. The intent was to keep things
easy to read and to prevent side effects. Over time, we began thinking this
restriction was unduly harsh. More precisely, we worried it that i
28 matches
Mail list logo
