[DESIGN] Effect of selectors on placeholders #755
Conversation
|
Adding some review requests... looking for early feedback and suggestions. |
There was a problem hiding this comment.
This does a good job of laying out the alternatives. The use of "side effect" or "mutable" should be avoided, since the only thing being talked about is name binding, and likewise, since we're talking about name binding, it should be clarified when "operands" really means "variables". On the whole, I was able to follow it and I can't think of any missing alternatives (except for doing nothing.)
|
|
||
| In this alternative, selectors are treated as declaration-selectors. | ||
| That is, an annotation in a selector works like a `.input`. | ||
| However, it is an error for the selector to try to modify a previous declaration |
There was a problem hiding this comment.
| However, it is an error for the selector to try to modify a previous declaration | |
| However, it is an error for the selector to shadow a previous declaration |
| (just as it is an error for a declaration to try to modify a previous declaration). | ||
| This permits `.match` selectors to be a shorthand when no declarations exist. | ||
|
|
||
| It is also an error for a selector to modify a previous selector. |
There was a problem hiding this comment.
| It is also an error for a selector to modify a previous selector. | |
| It is also an error for a selector to shadow a previous selector. |
(Again, this needs some qualifiers... writing .match {-1 :integer} {-1 :number} shouldn't be an error.)
There was a problem hiding this comment.
The example you gave doesn't modify a previous selector: the literal -1 in the first is a separate literal from that in the second. "Shadow" doesn't really say what is going on?
There was a problem hiding this comment.
If a selector implicitly introduces a name, then what you're referring to as "modifying" is actually "shadowing". If you write, in this scenario:
.match {$x :integer} {$x :number}
then the second $x doesn't modify the first one. Rather, it introduces a new name $x, so that in the patterns in the variants, $x now has a different meaning. That's what I mean by name shadowing.
There was a problem hiding this comment.
$x (a variable by the name of x in the formatting context) is different from the literal -1 (which is just a string--in your example, the second one is a different string that contains the same characters as the first).
I'm steering clear of "shadowing" because the thing that is or is not affected is the (ill-defined) "resolved value" in the formatting context (which I tend to think of as a Map<String,ResolvedValue>). I think it is clearer to say that the second $x in your example is "trying to modify" the resolved value of $x in the formatting context.
| - Enables representation of many messages without any declarations | ||
|
|
||
| **Cons** | ||
| - Confusing that the operand name can't be used in the pattern? |
There was a problem hiding this comment.
Why does the operand name have to be disallowed from appearing in the pattern?
There was a problem hiding this comment.
Perhaps not worded correctly. You can use the operand name in the pattern, but it's annotation won't/might not be applied.
.match {$count :integer}
* {{You have {$count} apples might print 2 or 2.0 with input count=|2.0|}}
There was a problem hiding this comment.
Right, so maybe something like: "The meaning of the operand name in the context of the pattern might not be what the user expects"?
Co-authored-by: Eemeli Aro <eemeli@mozilla.com>
Co-authored-by: Tim Chevalier <tjc@igalia.com>
Co-authored-by: Tim Chevalier <tjc@igalia.com>
Co-authored-by: Tim Chevalier <tjc@igalia.com>
Co-authored-by: Tim Chevalier <tjc@igalia.com>
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Fixes #736, Works on #747
This design document describes the effect of selectors on subsequent pattern placeholders of the same operand. It presents several alternatives.
This is still in "DRAFT" form and not yet ready for the WG as a whole.