Re: [External] : Re: Proposal: java.lang.runtime.Carrier

On 9 Mar 2022, at 6:28, Brian Goetz wrote: >> Also, i wonder if the external Carrier API should have a way to wrap an >> existing record class to see it as a Carrier, so the destructuring pattern >> will behave the same way with a record or with the result of a >> de-constructor. > >

Re: Proposal: java.lang.runtime.Carrier

ClassSpecializer is designed for cases beyond generating tuples, where some extra behavioral contract, and/or fixed field set, is required across all the generated classes. That said, ClassSpecializer should support tuple generation nicely, for Carrier. Maurizio’s point is a good one,

Re: [External] : Re: Proposal: java.lang.runtime.Carrier

FWIW I agree with Dan’s point. The Carrier API should throw IAE if Object does *not* appear in all the MethodType places where the eventual (mysterious encapsulated) carrier object will appear. If tomorrow we figure out a clever use for client-specified types there (such as Record or List),

Re: [External] : Re: Proposal: java.lang.runtime.Carrier

On 7 Mar 2022, at 16:07, fo...@univ-mlv.fr wrote: Not necessarily, while java.lang.Object appears in the bytecode a JIT like c2 propagates the real type of the constants (here empty() is typed with the type of the carrier not with java.lang.Object at runtime) so introducing null may introduce

Re: Proposal: java.lang.runtime.Carrier

Yes, ClassSpecializer was consciously designed to support structures like carrier instances, as well as bound method handles (which are a kind of carrier++).

Re: [External] : Re: Primitive type patterns

On 26 Feb 2022, at 8:49, Brian Goetz wrote: …I think they mostly proceed from two places where we may continue to disagree:  - You are generally much more inclined to say "if it might be null, disallow it / throw eagerly" than I am.  In general, I prefer to let the nulls flow until they hit

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

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

Re: [External] : Effectively final loop counter (was: Are templated string embedded expressions "method parameters" or "lambdas"?)

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 f

Re: [External] : Effectively final loop counter (was: Are templated string embedded expressions "method parameters" or "lambdas"?)

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

Re: Effectively final loop counter (was: Are templated string embedded expressions "method parameters" or "lambdas"?)

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

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

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 (co

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

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

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

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

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

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(()

Re: String Tapas Redux: Beyond mere string interpolation

On Sep 17, 2021, at 3:49 AM, Tagir Valeev mailto:amae...@gmail.com>> wrote: Another alternative is to have a single list of template fragments, something like this: Probably the VM will prefer to see a single string. There are lots of unused Unicode points that can serve as segment markers.

Re: String Tapas Redux: Beyond mere string interpolation

Yay! I agree with Brian’s response to Remi: Nothing new here regarding eval or ASTs. My favorite wished-for-use-case for templated strings is a grammar where the “holes” are grammar actions or other configuration points for rules. This paper made me envious for the sake of Java, and also made

Re: Using switch patterns to rewrite Arrays.deepHashCode

On Sep 11, 2021, at 11:42 AM, John Rose mailto:john.r.r...@oracle.com>> wrote: Putting Object[] at the top forces a re-evaluation when Valhalla comes, since the code will break. P.S. I wonder if there is a compatibility move where errors which arise from changed type relations (int <

Re: Using switch patterns to rewrite Arrays.deepHashCode

On Sep 11, 2021, at 6:48 AM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: You would need to reorder this switch! Because byte[] will be a subtype of Object[]. In Valhalla, that is. Putting Object[] at the bottom will absorb any and all “new primitives”. In fact, the “old primitives”

Re: Dominance in pattern matching for switch: Spec and Javac inconsistency

loss of information; that lets us write the desugaring without generating static temp variables. But an indy-generating expression is not clone-able, unless its BSM is constrained somehow.) On Sep 6, 2021, at 2:09 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: FTR, I approve of no

Re: Dominance in pattern matching for switch: Spec and Javac inconsistency

FTR, I approve of not even stepping onto this slippery slope. Doing so would seem to promise something of value to users, a promise they’d probably feel we would break by the draconian restrictions (with or without complex case analysis on statically kennable expressions). Remi, this relates to

Re: Dominance in pattern matching for switch: Spec and Javac inconsistency

On Sep 3, 2021, at 7:00 AM, fo...@univ-mlv.fr wrote: > > > but a guarded switch dominates it's prefix, > e.eg > case Integer i && foo(i) dominates case Integer. > > But there is no rule between a guarded pattern like case Integer i && foo(i) > and case 1, so they can appear in any order. >

Re: Revisiting the rule for merging type patterns ?

On Aug 30, 2021, at 9:08 AM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: This was always the intent. Recall that we discussed cases like: case IntBox(int x), IntBag(int x): and backed away not because they were unsound, but because they presented confusing questions like "where is

Re: Revisiting the rule for merging type patterns ?

On Aug 28, 2021, at 2:42 PM, Remi Forax mailto:fo...@univ-mlv.fr>> wrote: I think we should revisit that discussion and just not introduce the any bindings in that case so the example above will compile but "literal" or "funcall" are not added as local variable. Some partial comments:

Re: [External] : Re: Minor improvement to anonymous classes

+1 on removing unused this$1 > On Jul 31, 2021, at 12:51 PM, Brian Goetz wrote: > >  > >> Another option that gets some of the benefit and doesn't require a spec >> change is to omit the reference to the enclosing instance if it is unused. >> We've been doing that successfully for a few

Re: Minor improvement to anonymous classes

On Jul 30, 2021, at 8:55 PM, Tagir Valeev mailto:amae...@gmail.com>> wrote: 2. Allow new {...} instead of new Object() {…}. I would think *that* would make a very useful poly expression. Building “new Object() {…}” has far fewer use cases than “build me an object of the type the context

Re: Minor improvement to anonymous classes

It seems reasonable: If you can do this for lambdas, which are (sort of) a concise anonymous inner class notation, you should be able to do this with the next level of notation, anonymous inner classes. It’s ungraceful to have MI on lambdas and named inner classes, but not the intermediate

Re: Experience with sealed classes & the "same package" rule

On Jun 22, 2021, at 2:08 AM, Remi Forax wrote: > > The proposed simplification allows different packages to share different part > of the sealed hierarchy without a module. > So those packages can be in different jars, compiled at different times. > This will produce "impossible" sealed

Re: Experience with sealed classes & the "same package" rule

On Jun 21, 2021, at 6:10 AM, Maurizio Cimadamore mailto:maurizio.cimadam...@oracle.com>> wrote: Could we live w/o that rule? Sure we probably could, but let's not assume that dropping that rule is "free": the Panama API/impl would have to be refactored pretty heavily to take advantage of

Re: Experience with sealed classes & the "same package" rule

On Jun 9, 2021, at 3:20 PM, Remi Forax mailto:fo...@univ-mlv.fr>> wrote: Sealed hierarchies are restricted to a package in the unamed module in order to ease the migration when you add a module-info because a sealed hierarchy restricted to a package is obviously restricted to a module. Adding

Re: Experience with sealed classes & the "same package" rule

On Jun 9, 2021, at 2:42 PM, Dan Smith mailto:daniel.sm...@oracle.com>> wrote: Here's some late feedback on the sealed classes preview. Probably actionable before 17 GA, if that's what people want to do, or potentially a change that can come in a future release. (Or you can just tell me that

Re: [External] : Re: Rehabilitating switch -- a scorecard

On May 18, 2021, at 12:33 PM, Guy Steele mailto:guy.ste...@oracle.com>> wrote: If only we had tail calls. Then instead of writing (int q, int r) = quotientAndRemainder(m, n); whatever we could write (using my preferred syntax for a mandatory tail call in Java) goto quotientAndRemainder(m, n,

Re: Rehabilitating switch -- a scorecard

In May 17, 2021, at 4:36 PM, Brian Goetz wrote: > > I think we've done a remarkable job at rehabilitating this monster. +100, especially after re-reading your 2017 document. > *Someone actually suggested using the syntax "new switch", on the basis that > new was already a keyword. Would

Re: Switch labels (null again), some tweaking

On Apr 29, 2021, at 8:19 AM, fo...@univ-mlv.fr wrote: and let the runtime part bound to invokedynamic to take care of the remainder. +100 and another +100 for the term-of-art “spiny”

Re: Switch labels (null again), some tweaking

On Apr 27, 2021, at 9:39 AM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: Where I think we need to shore up the story is in "how do I turn on exhaustiveness checking for statement switches.” Yes, the non-exhaustiveness of legacy switches turns out to be a hiding place for bugs and

Re: [External] : Re: Switch labels (null again), some tweaking

On Apr 23, 2021, at 1:38 PM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: On 4/23/2021 4:25 PM, Remi Forax wrote: Bottom line: Trust the users to choose how explicit to be with nulls. More importantly, trust them with compositional notations. That's a solution, we do nothing and

Re: Switch labels (null again), some tweaking

On Apr 23, 2021, at 1:10 PM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: I think the concern on the part of the null-fearers is not so much the O(n) scan (though that's a concern), as much as the subtle difference between `case Object o` and `default`. They are almost identical, except

Re: [sealed-types] Draft Spec for JEP 409 Sealed Types (Final)

On Apr 20, 2021, at 2:00 AM, Gavin Bierman wrote: > > > http://cr.openjdk.java.net/~gbierman/jep409/latest/ Out of curiosity I compared the two large new sections on permits, 8.1.4 and 9.1.4, perhaps to find unintentional divergences. Here are the differences I found FYI, aside from than the

Re: Switch labels (null again), some tweaking

On Apr 23, 2021, at 8:38 AM, Brian Goetz wrote: > > ...The fact is that the natural interpretation of a total type pattern is > that it matches null. People don't like this… This person does. As you point out, this position enables composition of patterns. And composition is the more

Re: Guards redux

On Mar 10, 2021, at 11:29 AM, Guy Steele wrote: > > Let me suggest this alternative: > > Pattern: > : ConditionalOrPattern > : ConditionalAndPattern `&&` Guard Clever. Too bad we can’t do this for expressions too. >> Guard: >> : AssignmentExpression > > Yes, “AssignmentExpression” is the

Re: [External] : Re: Guards redux

On Mar 10, 2021, at 11:10 AM, Guy Steele wrote: > > But in principle it does matter for patterns, because while patterns arguably > do not involve _evaluation_, they most certainly involve _execution_ of > possibly user-written code. If side effects can occur, the distinction > arguably

Re: Guards redux

On Mar 10, 2021, at 8:33 AM, Remi Forax wrote: > > As i said to Gavin, i'm not at ease with using the symbol '&' in between > patterns. Aren’t patterns inherently sequential and short-circuiting? Or am I having a failure of imagination? All of the pattern syntaxes mimic expression syntaxes,

Re: Guards redux

Good. PrimaryPattern is a good concept. On Mar 10, 2021, at 6:47 AM, Gavin Bierman wrote: > > Guard: > : AssignmentExpression I think it should be this instead: Guard: : ConditionalAndExpression The effects of this narrower definition of a guard expression are two: First, any guard of the

Re: [External] : Re: Guards

On Mar 9, 2021, at 2:57 PM, fo...@univ-mlv.fr wrote: > > > > De: "John Rose" > À: "Remi Forax" > Cc: "Brian Goetz" , "amber-spec-experts" > > Envoyé: Mardi 9 Mars 2021 23:05:28 > Objet: Re: [External] : Re: Guards > O

Re: [External] : Re: Guards

On Mar 9, 2021, at 1:45 PM, fo...@univ-mlv.fr wrote: > > I see the pattern + parameters has a partial application, i.e. the parameters > other than the target are constants, > the keys of the map are constant, the java.util.regex.Pattern (or the string) > of a metch is a constant, etc > > So

Re: [External] : Re: Fwd: Two new draft pattern matching JEPs

On Mar 9, 2021, at 12:23 PM, John Rose wrote: > > If switch refactors > to an if-chain, why then continue-switch would refactor to > continue-if, which turns out to branch to the next “else”, > if any. A bit more detail in case that was cryptic: switch (obj) { ... case P & G

Re: [External] : Re: Fwd: Two new draft pattern matching JEPs

On Mar 5, 2021, at 8:29 AM, Brian Goetz wrote: > >> >> The one objection I still have to grobble is one I've raised before: it >> makes it hard to imagine ever representing disjunctions as guards. I always >> bring up stuff like >> >> switch (people) { >> case Pair(Person(String name1, int

Re: [External] : Re: Guards

On Mar 9, 2021, at 10:47 AM, Brian Goetz wrote: > > >> Apart from what have said about letting grobble to fully access to the >> bindings > > Except that argument doesn't make sense. Accessing the bindings is not a > special behavior of grobble, but a natural consequence of flow scoping.

Re: Guards

On Mar 5, 2021, at 3:08 PM, John Rose wrote: > > s/when/&&/ is my proposal; then & is the visual cue, > and you can stack them. (If you want || or ?:, you will need > to use parens.) The grammatical way to say this is that a switch case pattern can

Re: [External] : Re: Two new draft pattern matching JEPs

On Mar 4, 2021, at 8:28 AM, Brian Goetz wrote: > > A lot of people (initially, me included) would like to just interpret a > boolean expression as a pattern: > > case Foo(var x, var y) && x > y: ... > > I found that goal compelling, but as patterns get more complicated, this gets >

Re: Two new draft pattern matching JEPs

I did careful pass over the docs and here are a couple more comments. You anticipated them at the end with the “here’s what else we might do” section. The “as” pattern which binds a value before doing more pattern matching on it should can be synthesized from “var” and “&”, as “P & var x”. The

Re: Two new draft pattern matching JEPs

On Mar 5, 2021, at 2:41 PM, Guy Steele wrote: > >> because at the point where the pattern true(...) is evaluated, the Rectangle >> has already been destructured, obviously, we can ban this kind of patterns >> to try to conserve the left to right evaluation but the it will still leak >> in a

Re: Guards

On Mar 5, 2021, at 3:11 PM, Brian Goetz wrote: > > > Or: > > case &: Yes, I was reticent about that, but perhaps unary “&&” is a reasonable marker for “go into expression land”. It could also help to mark in-args for deconstructor methods.

Re: Guards

Guy, I think you are right that guards have a natural home on the right-hand edge of patterns (whether the patterns are simple P or composite P, etc). And because patterns can nest, this “right edge” can occur placed inside a sub-pattern, which lets us smuggle guards anywhere we like, with a

Re: [External] : Pattern assignment statements (extracted from: Primitive type patterns and conversions)

On Mar 3, 2021, at 11:52 PM, fo...@univ-mlv.fr wrote: >> >> First, I agree with Brian that “int data[] = …” >> is horrible; we should have only allowed >> “int[] data = …” and taken the hit early. >> > There is also its big brother > int foo() [] { return null; } > which is the epitome of the

Re: Primitive type patterns and conversions

On Mar 1, 2021, at 2:04 PM, Brian Goetz wrote: > > Right now, we've spent almost all our time on patterns whose targets are > reference types (type patterns, record patterns, array patterns, > deconstruction patterns). It's getting to be time to nail down (a) > the semantics of

Re: [External] : Pattern assignment statements (extracted from: Primitive type patterns and conversions)

On Mar 3, 2021, at 8:09 AM, Brian Goetz wrote: > >> the whole story about initializing a local variable with an array is weird, >> int data[] = {1, 2, 3}; >> compiles but >> int data[]; >> data = {1, 2, 3}; >> does not. > > True, and I hate it. This is related to the C-style array decl;

Re: Relaxed assignment conversions for sealed types

On Jan 22, 2021, at 9:27 AM, Brian Goetz wrote: > > I want to pick up on this thread, now that we may have some more fire to add > to it, and we've all had some time to think about it. > > - The main technical debt that we piled up when doing switch expressions is > that switch expressions

Re: Should final fields in records be trusted or not trusted in 16?

On Dec 10, 2020, at 11:46 AM, John Rose wrote: > > We don’t have a complete solution yet, but that does not > mandate protecting fields we know can merit special > protection. (Oops, meant to say something like “that incompleteness does not prevent us from protecting fields that w

Re: Should final fields in records be trusted or not trusted in 16?

On Dec 10, 2020, at 6:35 AM, Chris Hegarty wrote: > > >> On 10 Dec 2020, at 14:11, fo...@univ-mlv.fr wrote: >>> ... >> >> There is a third choice see above. >> >> Forcing the semantics of Java into the VM is always a bad idea. >> We don't do that for any other

Re: [statics] allowing static initializers in interfaces?

. This pattern has the advantage of allowing a single-keyword upgrade when private classes are eventually allowed, and also a pretty small (though non-empty) API footprint today. — John > - Mail original - >> De: "John Rose" >> À: "Maurizio Cimadamor

Re: [statics] allowing static initializers in interfaces?

+1 from me too, and generally to heal the rift. The inability to put private classes (and other “stuff”) in an interface makes it hard to support canonical algorithms in default methods, if they need auxiliary types. > On Nov 17, 2020, at 6:03 AM, Maurizio Cimadamore > wrote: > > Hi, > now

Re: getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

On Oct 24, 2020, at 3:32 PM, fo...@univ-mlv.fr wrote: > > the 'get' was removed because the method was not returning Class objects, now > that permittedSubclasses behave like the other methods of java.lang.Class, > the name should be changed back to "get..." to reflect that. One reason (beyond

Re: Finalizing in JDK 16 - Pattern matching for instanceof

On Sep 23, 2020, at 12:14 PM, John Rose wrote: > I am convinced that (under broad presuppositions) reconstruction > expressions *should* allow mutation to their internal bindings. P.P.P.S. I updated my case study [1] to point at Brian’s more recent document [2], and realized that my

Re: Finalizing in JDK 16 - Pattern matching for instanceof

On Aug 26, 2020, at 8:00 AM, Brian Goetz wrote: > > …I now think that we have done the same with binding variables. Good catch; thank you! > Here are two motivating examples: > > (a) Pattern assignment… > (b) Reconstruction. We have analogized that a `with` expression: > > x with { B }

Re: Next up for patterns: type patterns in switch

OK, I’m going to make some *concise* responses to what appear to be the choice points in your Email. I’m going to leave aside the JEP document[1] for now. [1]: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html On Jun 24, 2020, at 7:44 AM, Brian Goetz wrote: > ... > ## Patterns

Re: A peek at the roadmap for pattern matching and more

P.S. I’m going to take Brian’s lead now and talk about the short-term matters immediately in front of us. It’s been fun… We’ll get back it later. > On Aug 13, 2020, at 5:17 PM, John Rose wrote: > > On Aug 13, 2020, at 4:53 PM, fo...@univ-mlv.fr <mailto:fo...@univ-mlv.fr> >

Re: A peek at the roadmap for pattern matching and more

On Aug 13, 2020, at 4:53 PM, fo...@univ-mlv.fr wrote: > > use it as an anonymous carrier of values to transfer the values from a plain > old class to a representation you can do destructuring on it Yes, something like that could play a role in reifying a “bundle of names coming out of a block”,

Re: A peek at the roadmap for pattern matching and more

On Aug 13, 2020, at 4:11 PM, fo...@univ-mlv.fr wrote: > > For me it's like having a complex lock on the front door and wanting to have > the same mechanism on the opposite side of the front door (to go out) because > you already know how to unlock the front door. Ow! Tough crowd. As you may

Re: A peek at the roadmap for pattern matching and more

On Aug 13, 2020, at 3:01 PM, Guy Steele wrote: > >> >> On Aug 13, 2020, at 5:37 PM, John Rose > <mailto:john.r.r...@oracle.com>> wrote: >> >> On Aug 13, 2020, at 12:39 PM, Guy Steele > <mailto:guy.ste...@oracle.com>> wrote: >>

Re: A peek at the roadmap for pattern matching and more

What you said! On Aug 13, 2020, at 1:14 PM, Brian Goetz wrote: > > By framing deconstructors as the arrow-reversed form of constructors, we > provide the missing edges in our graph in a symmetrical way. By framing > deconstruction as merely a "multi-getter", we may provide the missing edges,

Re: A peek at the roadmap for pattern matching and more

On Aug 13, 2020, at 12:39 PM, Guy Steele wrote: > > Whereas I can more easily understand that the job of > > public deconstructor Point(int x, int y) { > x = this.x; > y = this.y; > } > > is to take values out of the object “this” and put them into separate >

Re: A peek at the roadmap for pattern matching and more

On Aug 12, 2020, at 4:28 PM, Remi Forax wrote: > > > I know that you have consider something like this, but i prefer making the > deconstructor a method returning a tuple at Java level, to be closer to the > JVM level. > So a syntax more like > class Point { > int x; > int y; > >

Re: Next up for patterns: type patterns in switch

On Aug 4, 2020, at 11:11 AM, Brian Goetz wrote: > > One thing this left open was the actual syntax of guards. (We know its > snowing in hell now, because I am actually encouraging a syntax > conversation.) If this is only a “syntax of guards” discussion I have little to say, except that I

Re: Next up for patterns: type patterns in switch

On Jul 23, 2020, at 2:53 PM, Remi Forax wrote: > > var x and default are not on the same plane. So it's not really a third thing. > We are introducing something special for the bottom, null, but not for the > top ? Eh; null doesn’t need to be that special, but Brian’s point is that you can

Re: Next up for patterns: type patterns in switch

On Jul 23, 2020, at 3:15 PM, Remi Forax wrote: > > I want at least to be sure we have tried to corral mutable objects. The horse has left the corral.

Re: Next up for patterns: type patterns in switch

On Jul 23, 2020, at 3:48 PM, Brian Goetz wrote: > >> P.S. Well, not exactly. You didn’t expect *no* comment from me? :-) > > There's always one > >> It is slightly premature to completely outlaw `x instanceof 42`, >> because of nulls: You can replace that with `x == 42` only if `x` >>

Re: Next up for patterns: type patterns in switch

On Jul 23, 2020, at 11:38 AM, Remi Forax wrote: > > In next releases? Add constant Pattern and static Pattern. Ban instance > pattern because you don't want to match something that depends on a mutable > states (my worst experience with Scala). Do you mean mutable states in some sort of

Re: Next up for patterns: type patterns in switch

Just one comment here: This is a masterful summary of many months work pursuing hard-won insights; thank you; let’s do this. — John P.S. Well, not exactly. You didn’t expect *no* comment from me? :-) It is slightly premature to completely outlaw `x instanceof 42`, because of nulls: You can

Re: The case for no case

On Jun 4, 2020, at 2:17 AM, Remi Forax wrote: > > One simple solution is to use different keyword for different kind of > patterns, > by example, "case" for a constant pattern, "instanceof" for the type pattern, > "default" the default pattern, etc That strikes me as making the job of

Re: Record copy()/with()

On May 24, 2020, at 7:50 AM, fo...@univ-mlv.fr wrote: > ...I call it a “reconstructor”. > > yes, it's a good name. Glad you agree! > ...A reconstructor makes the most sense for an inline type, but it > also makes sense for identity types (as long as users are willing > to eat the cost of making

Re: Record copy()/with()

On May 23, 2020, at 9:07 AM, Remi Forax wrote: > >> >> 3. Record components could also be normalized in the constructor. E.g. >> assume record Fraction(int numerator, int denominator) that normalizes >> the components using GCD in the constructor. Using withers would >> produce a weird result

Re: Class & interface terminology

On May 8, 2020, at 12:59 PM, fo...@univ-mlv.fr wrote: > > > I'm not against replacing "type" as a generic term for all the construct. > You're using "type-declaring construct", and i think it's a better term that > "class and/or interface" because it convey the fact that this is an union of >

Re: getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

On May 9, 2020, at 2:00 PM, Remi Forax wrote: > ... > This BTW is one of many reasons we want a symbolic linkage mode > for indy and condy, in which the BSM is set to run on pre-resolved > ConstantDesc data. > > I think it's worst, you want some type arguments to be already resolved and > some

Re: getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

On May 9, 2020, at 12:59 PM, Dan Smith wrote: > > maybe a better long-term path to getting to a less brittle API is to design a > new, lower-level API, rather than trying to slowly introduce a new way of > doing things into java.lang.Class. Yes, that was my thought also. Probably because

Re: Class & interface terminology

On May 7, 2020, at 3:07 PM, fo...@univ-mlv.fr wrote: > > No, i disagree about to things > - trying to tilt each features to be either an interface or an class is not > appropriate I buy Dan’s argument that since the JLS uses this bifurcation, it is legitimate to extract more benefit from it in

Re: Class & interface terminology

On May 7, 2020, at 4:11 PM, Dan Smith wrote: > > I feel strongly that "class or interface" is better than "type", and that we > need to stop using "type" in this context. I'm agnostic about what we say > instead. But "class or interface" has the benefit that it's already used > pretty

Re: Possible records tweak

On Apr 29, 2020, at 11:55 AM, Dan Smith wrote: > >> On Apr 29, 2020, at 12:37 PM, John Rose wrote: >> >> So I’ve lost track of this bit: What happens if the compact constructor >> calls a virtual method on this? (Say it doesn’t explicitly mention ’this’.) >>

Re: Possible records tweak

On Apr 29, 2020, at 10:07 AM, Gavin Bierman wrote: > > Talking it through with Dan, I think the best thing for the JLS is to avoid > issues of `this` etc and simply state: > > It is a compile-time error to assign to the instance fields of the > record class in the body of the compact

Re: Record component type can be an inner class of a record

On Apr 28, 2020, at 9:53 AM, Dan Smith wrote: > > Unless AnotherADeclarer also declares a class named pa. :-) > > There is no 100% reliable desugaring to Java syntax. Thank you; I stand corrected! I needed a quick review of JLS 6.5.2.

Re: Record component type can be an inner class of a record

On Apr 20, 2020, at 3:32 PM, Dan Smith wrote: > > My point: there are no references to 'A' inside the body. The only reference > to 'A' in this program unambiguously refers to the top-level A. > > You seem to be assuming that there will be resolution problems involved in > checking the

Re: Possible records tweak

On Apr 24, 2020, at 12:43 PM, Dan Smith wrote: > >> On Apr 24, 2020, at 1:32 PM, Remi Forax wrote: >> >>> (Which, in hindsight, might have been a good rule for _all_ constructors, >>> if there was another way to initialize the fields. Surely would have >>> eliminated much verifier

Re: Possible records tweak

On Apr 24, 2020, at 11:24 AM, Brian Goetz wrote: > > the question I want to ask is: should we simply _ban_ reads and writes to > `this.x` in the body of a compact constructor, and let the auto mechanism > take care of it, so there is no confusion about mixing initialization modes, > the

ClassValue performance model and Record::toString

This note is prompted by work in a parallel project, Amber, on the implementation record types, but is properly a JVM question about JSR 292 functionality. Since we’ve got a quorum of experts here, and since we briefly raised the topic this morning on a Zoom chat, I’ll raise the question here of

Re: Semantics of an empty PermittedSubtypes attribute for the VM

On Apr 3, 2020, at 3:12 PM, John Rose wrote: > > - A “private action” is any action which the static compiler could have > arranged for. > - Private actions define encapsulation boundaries. (They can be made public, > protected, etc.) P.S. This is the important part. A clea

Re: Semantics of an empty PermittedSubtypes attribute for the VM

On Apr 3, 2020, at 2:42 PM, fo...@univ-mlv.fr wrote: > > And more generally, > should the VM offer a way to update the permitted subtypes list dynamically ? To me that’s an easy “yes”, in the setting of HCs at least. Here’s the reasoning: - A HC can be dynamically injected into a nest, by

Re: Semantics of an empty PermittedSubtypes attribute for the VM

On Apr 3, 2020, at 1:52 PM, Brian Goetz wrote: > > An easier way to get there might be: > > public sealed interface I > permits C { } > > private non-sealed abstract class C implements I { } > > and have the HCs extend C. Also, as a special case, if no such HCs ever show up,

Re: Semantics of an empty PermittedSubtypes attribute for the VM

C. > > On 4/3/2020 4:48 PM, John Rose wrote: >> On Apr 3, 2020, at 1:36 PM, Brian Goetz >> <mailto:brian.go...@oracle.com> wrote: >>> I'm mostly thinking of interfaces that will only be implemented by hidden >>> classes. >> In order to do tha

Re: Semantics of an empty PermittedSubtypes attribute for the VM

On Apr 3, 2020, at 1:36 PM, Brian Goetz wrote: > > I'm mostly thinking of interfaces that will only be implemented by hidden > classes. In order to do that we need a way to hook the HCs into the permits list. That can be done with a private abstract class that nobody extends except the

Re: Semantics of an empty PermittedSubtypes attribute for the VM

On Apr 2, 2020, at 4:58 AM, Remi Forax wrote: > > the implementation in Hotspot ignores the attribute PermittedSubtypes if > there is no subtype listed AFAICT this behavior is an accident of prototype engineering, and I’m glad we are clarifying it to be illegal. Here are principles that I

Re: do expression

On Mar 24, 2020, at 8:19 PM, Tagir Valeev wrote: > > It looks weird to me. An arrow assumes some left-hand 'from' part, but > it's absent here. Also, too easy to mix with actual lambda, to my > taste. Still, better than nothing :-) To me the interesting observation here is that we already have

  1   2   3   >