[External] : Re: Guards

[John Rose]

On Mar 9, 2021, at 1:45 PM, 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.

Moreover, I think you want patterns to *reject*
non-constant operands, so that such configurations
are reliably done before first execution.

I whole-heartedly agree with the first goal,
but I think the second would be a bridge too
far, because various kinds of refactorings
can shift expressions in and out of the
“constant” category, and that’s useful.

I think we can trust users to use constants
in places where they are advantageous.

You may well ask, “but what is the language
support for reliably folding constants at
javac translation time?”  And the answer
is “nothing yet”.  But I think that is a job
for Brian’s constant-folding mechanisms,
building on top of his ConstantDesc work.
Until that point, we can live with non-constant
expressions.  I would say, before that point,
it would be foolish to add indy support for
constant in-args, just for and only for patterns.

— John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210309/86704a37/attachment.htm>