On Mar 9, 2021, at 2:57 PM, fo...@univ-mlv.fr wrote: > > > > De: "John Rose" <john.r.r...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Brian Goetz" <brian.go...@oracle.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Envoyé: Mardi 9 Mars 2021 23:05:28 > Objet: Re: [External] : Re: Guards > On Mar 9, 2021, at 1:45 PM, fo...@univ-mlv.fr <mailto: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 yes, a pattern have input parameters other than the target but should they > have access to the bindings, i think we are loosing a lot with that model. > > If I read you correctly, you want patterns to be > as statically scrutable as possible, so that translation > strategies can boil together as much of the pattern > as possible before first execution, typically using > indy or condy to do “advanced” configuration > and optimization of statement logic. > > Not for the translation strategy, just to be able to rapidly read all the > patterns without having to precisely follow the control flow. > I would like to have the horizontal reading to be as simple as possible so > you can grasp the whole pattern matching vertically. > Another way to see it is to see Pattern as declarations more than expressions.
OK. So you are saying you are OK with northward dependencies on non-constant data (names of locals, etc.) but not westward. (BTW, we all agree that southward and westward dependencies are harder to cope with. Note, however, that Java declaration syntax has a prevailing eastward dependency, from the initializer. Just something to keep in mind for later.) When you say “horizontal reading”, I note that one *does* read westward dependencies before reading content to the east, but I think you want the whole line to be readable at once. Well, that’s fine, but it’s not clear that is a hard constraint on what we are designing. A coder can code that way. Even with guards, the “&&G” part can and sometimes should be put on its own line, south of the pattern. I can derive a soft requirement out of your point, and that is that “it would be nice” if “westward” dependencies in patterns are hard to hide. The “&&” operator fulfills this requirement for guards, since “&&” is relatively bold in appearance (easy to spot) and is not used for patterns. This is also the reason I (very tentatively) suggested that a unary version of the “&&” syntax might also be useful for marking in-arguments inside of patterns. If that suggestion doesn’t fly, maybe we can come up with some other marker for pattern in-args in general, or maybe just for “westward in-args in the same pattern”, that serves the purpose of making them stand out. (And without committing the newbie error of Always Making the NEW Feature **Stand OUT**, with h/t to Neal Gafter.) Happily, we can solve the general problem of in-arg marking separately from this design iteration. — John
