Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Clarify err:XS0091 #826
I don't really understand this paragraph:
You can't have two options with the same name, so that case isn't relevant.
The first part of that paragraph talks about "within the prolog" but then we say variables and options within the subpipeline can shadow each othere, except for the casual remark about not shadowing preceding static variables.
Looking at my notes from Leipzig last year, the answer to (1) is pure pragmatic. If they can't be shadowed you do not have to build a scope to find out the last shadowing, which is the real value.
I do not think it is worth it to allow scoping: Static variables are constants and a goody for pipeline authors because they do not have to write / change the same value over and over again. All this can be done without scoping -> choose another name for the new variable.
Concerning (2) I have to think about it.
I think what we were talking about is something like this:
I do not like our solution either. If static options are basically static variables coming from the outside (the processor), I would argue they can only be declared in the outer most
If the option is set from the outside, it is pointless, because
The example above is what I meant, but note that this is flatly invalid: you can't have two options on the same step with the same name.
In the earlier example, where a static option is declared in a nested step, the same rules apply. The expression that initializes that option must be computed statically and can refer to statics that are already in-scope. (Or that's how I understood it, anyway.)
Sorry, I lost track. I was trying to explain why
I try to give an example what this means (because static option to my reading establish only one scope since there is no way to set them).
Do you actually propose to make the minor goody of static options/variables such a big thing. As I said, to me they make sense in the outermost pipeline and shouldn't be declarable in nested steps.
I know that we disagree in this point and we decided to follow your opinion. But imho that can't be the reason to make static options/variables a monster.
Yes, but that does not mean inner and outer pipelines have to be the same. Remember my argument was to allow static option/variable declaration in a p:library. So if a step to be imported relies on a static option/variable, they have to be put in a p:library.
But I think we should not open up this discussion again. If I remember right, the rule "do not shadow static options/variables" was a consequence of allowing their declaration "everywhere" and the need to find a simple solution. You might say you do not want a simple solution anymore. But then we should concentrate the discussion on this point and its consequences.
I am not sure I even understand the semantics of shadowing a static option. But may be this is just my problem.
I think I found the reason in my notes, why static variables do not shadow: Suppose
What is the value of the imported variable? We need to make a rule for this.
The spec is unclear and self-contradictory so I don't believe that the decision was adequately recorded.
Observation: we went to a lot of trouble to make sure that variables and options (henceforth "variables", but I mean both) behave in the way users expect. We allow them anywhere and we allow them to shadow.
Assertion: the principle of least surprise should apply. A user who understands how variables work shouldn't be surprised by the behavior of a variable just because it's static.
At any given point where an expression occurs, there is an unambiguous set of in-scope variables. Those are the ones that are used to evaluate the expression. If the variable is static, then any reference to non-static variables (or the context node) is an error.
I'm a little unclear on how we intended a p:option in a p:library to ever get a different value at runtime, I suppose we could imagine a global context in which initial static option values are known. We probably need to be explicit about what happens in this case:
And a pipeline:
I think a case could be made for any of the three possible values. If the 'runtimevalue' is provided, I expect the only useful answer is 'runtimevalue. If no runtime value is provided, I'm inclined to say that the value should be
Consider this library:
I assume the idea here is that $foo can be set once and used in multiple pipelines, which is handy.
Note that the pipelines could not have any other inner declaration of
And in any event, are we really sure that static values from the "outer context" at runtime flow through into pipelines nested in libraries nested in pipelines nested in libraries?