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