Skip to content

Commit 132d9c3

Browse files
aphillipsaphillips
authored
Create notes-2024-08-12.md
1 parent 1c1bb37 commit 132d9c3

File tree

1 file changed

+151
-0
lines changed

1 file changed

+151
-0
lines changed

‎meetings/2024/notes-2024-08-12.md‎

Lines changed: 151 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,151 @@
1+
# 12 August 2024 | MessageFormat Working Group Teleconference
2+
3+
### Attendees
4+
- Addison Phillips - Unicode (APP) - chair
5+
- Elango Cheran - Google (ECH)
6+
- Mihai Niță - Google (MIH)
7+
- Tim Chevalier - Igalia (TIM)
8+
- Richard Gibson - OpenJSF (RGN)
9+
- Luca Casonato - Deno (LCA)
10+
11+
Scribe: RGN
12+
13+
## Topic: Info Share
14+
15+
ECH: [Unicode Technology Workshop](https://www.unicode.org/events/utw/) is happening Oct 22-23. Today is the last day for submitting proposals. Registration is open.
16+
17+
### Feedback
18+
19+
APP: #852 (more below)
20+
21+
### Add Duplicate Variant error (#853)
22+
23+
LCA: proposal to permit implementations that don’t enforce this, such as very lightweight IoT
24+
25+
APP: But the implementation will still need to perform matching. What if you have more than one all-stars key?
26+
27+
## Topic: Selection-declaration (#824)
28+
_Discuss the design options seeking WG consensus. Timeboxed to 15 minutes or will go to ballot._
29+
30+
https://github.com/unicode-org/message-format-wg/blob/main/exploration/selection-declaration.md
31+
32+
ECH: I’m not strongly opinionated yet, but would like to hear from others. What are the benefits of the change?
33+
34+
MIH: It is common to select on… it is a burden to impose declarations.
35+
36+
APP: The solutions I favor are only for input variables. It will seem natural to users.
37+
38+
APP: But the reason I prefer the immutable version is that we’ve gone out of our way to ensure immutability elsewhere. There are shortcomings to that for e.g. dates, but I’m willing to impose locals for such cases in order to simplify things.
39+
40+
APP: EAO’s preference is to match on variables directly without braces, but I think that’s a syntax problem.
41+
42+
LCA: My position feels like a mix… the current situation is unfortunate because you have a value that cannot be referenced. I would prefer immutable with inline declaration or…? Both clarify that just an expression with no assignment does not modify anything.
43+
44+
MIH: This is to solve the problem where a message selects on one thing and then displays something else. But it’s clunky to repeat formatting inside each variant, which favors adding declarations anyway.
45+
46+
APP: Look at use case 3… this is a current issue that the proposal is attempting to solve.
47+
48+
ECH: This conversation has swayed me in favor of mutable input declarative selectors, but I want to make sure I understand the difference between that and “Allow both local and input declarative selectors with immutability”.
49+
50+
APP: I’m advocating for the former.
51+
52+
ECH: Great, me too.
53+
54+
<general confusion regarding Duplicate Declaration errors>
55+
56+
LCA: I do like “Allow both local and input declarative selectors with immutability”. It’s confusing that .input performs casting on input but .local does not. There’s another issue about the strange behavior of .input.
57+
58+
APP: Today, .input doesn’t affect a .match selector affect each other, which itself is weird:
59+
```
60+
.input {$num :number minFracDig=1}
61+
.match{$num :integer}
62+
* {{This formats {$num} as 1.1}}
63+
```
64+
65+
LCA: I think we have the same intuition but different points of confusion. I don’t see why .match should be like .input rather than .local… I find .input to be the odd one out.
66+
67+
LCA: APP has the intuition that .match should behave like .input, but I’m concerned about users with the opposite intuition, that expect .match to *not* affect its selector.
68+
69+
APP: In what cases would you not want the selector to affect formatting?
70+
71+
LCA: A value that is a list of items and a function that reports empty vs. non-empty… you wouldn’t want the function to replace its value with a boolean.
72+
73+
APP: Use case 6 is relevant.
74+
75+
MIH: I think we don’t need this—better to not support function/option annotation for .match selectors at all.
76+
77+
RGN: I think I share LCA’s intuition very strongly, and until this discussion, I didn’t understand what irritated me about the behavior of .input. This really draws it into focus.
78+
79+
ECH: It seems like there’s more than one thing going on here… selecting and mutating at the same time. I don’t like any of the new options, which add complexity.
80+
81+
APP: You don’t see a challenge with “do nothing” having annotation of a selector not affecting any binding?
82+
83+
ECH: Right, it should be free of side effects.
84+
85+
APP: But there’s no duplicate declaration error when you .match against an expression that does have annotations.
86+
87+
APP: We’ve exhausted the time box… should this be balloted?
88+
89+
LCA: We’ve all encountered some new information; let’s revisit next week.
90+
91+
## Topic: Disallow “whitespace or special char” prefixed `.` in reserved-statement’s body (#840)
92+
93+
_Discuss making this small technical change in the reserved-statement syntax._
94+
95+
LCA: To start with the problem: reserved-statement is so lax that an error-recovering parser can accept messages that probably shouldn’t be recognized as valid. There’s an example in the PR:
96+
```
97+
.foobar $var =
98+
.local $count = {1}
99+
{{The count is {$count}.}}
100+
```
101+
102+
LCA: This pretty clearly starts with an invalid declaration, but unfortunately parses as valid.
103+
104+
LCA: I’m specifically disallowing dots that are not immediately following a valid name character.
105+
106+
MIH: Would you want the same kind of recovery if the keyword is valid?
107+
108+
LCA: Yes, but it’s not really relevant because messages like that aren’t syntactically valid.
109+
110+
MIH: An error is an error; runtime behavior shouldn’t be doing something like this.
111+
112+
LCA: Absolutely. This is entirely for tooling. The only reason that I am bringing this up is because if I want to error-recover from this in tooling, I cannot because this is a valid statement.
113+
114+
RGN: That got to exactly the issue that I was going to raise. There is something to fix here, but I’m not convinced that this is the way to fix it. Because there is the possibility for future extensions that support nested statements. I need to review the reserved-statements specification, and I think it is too lax for what it permits, and there is still time to change it. I like the framing of looking at this from the perspective of error-recovering parsers.
115+
116+
MIH: RGN summarized my take. I have an issue filed against reserved statements because the definition is very very lax to the point that we allow all sorts of behavior that can be very deeply nested and messy.
117+
118+
APP: What is the syntax theory of our grammar? If we had a syntax theory of our grammar, that would help. Currently, all of our statements end with a curly bracket. Our reserved statements are too lax, they can contain all sorts of goo and such. In many programming languages, all statements are terminated by a semicolon. So when when you see a semicolon, you know that the construct that you’ve seen has ended.
119+
120+
APP: I think the design doc is a good place to work on this.
121+
122+
LCA: To summarize, there’s general consensus for making reserved-statement more restrictive and working on proposals as a design doc.
123+
124+
## Topic: Bidi design (#811)
125+
126+
_Merge this design document and then discuss bidi options._
127+
128+
https://github.com/unicode-org/message-format-wg/blob/main/exploration/bidi-usability.md
129+
130+
APP: I have a proposed design, but am not fully happy with it. I’m inclined towards hybrid approaches that relax the syntax but support some BIDI controls outside of patterns and provide a clear recommended structure to use when being strict.
131+
132+
ECH: Unicode is hosting a webinar tomorrow in a series on BIDI. Register at https://unicode.org/events/ . The recording for part 1 is already available at: https://youtube.com/@unicode -> https://youtu.be/TWfvRdS_7x0?si=o2m12Idwt1O3yj2r
133+
134+
## Topic: Registry maintenance (#634)
135+
136+
_This is the function registry maintenance procedure design. Let’s review with an eye towards using as a template for other work._
137+
138+
https://github.com/unicode-org/message-format-wg/pull/634
139+
140+
APP: There are functions (and options of functions) which implementations are not required to support, but if they do support, should do so in a standard way, covered in the function registry. This is an attempt to document registry maintenance and extension processes.
141+
142+
## Topic: Function use outside its intent (#852) (Agenda+)
143+
144+
https://github.com/unicode-org/message-format-wg/issues/852
145+
146+
(discussion, decided to reject this issue as addressed by existing text)
147+
148+
## MEETING ADJOURNED
149+
150+
151+

0 commit comments

Comments
 (0)