[External] : Re: Guards
john.r.rose at oracle.com
Wed Mar 10 00:04:02 UTC 2021
On Mar 9, 2021, at 2:57 PM, forax at univ-mlv.fr wrote:
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 9 Mars 2021 23:05:28
> Objet: Re: [External] : Re: Guards
> On Mar 9, 2021, at 1:45 PM, forax at univ-mlv.fr <mailto:forax at 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts