Translator from GHC Core to Isabelle/HOLCF
Simple utility for interfacing between iTunes and an MP3 player
Hosted servo test cases
CIS 27 Spring 2020 code
A work-in-progress programming language; not yet suitable for users
Test package for rustpkg
The content behind MDN Web Docs
A simple non intrusive resource pool for connections
Internet history forensics for Google Chrome/Chromium
The home of the ICU project source code.
push eventcatamorphism/icu
commit sha b66bda2cea8dc8ec21532407e2a45c9bdc766bc4
Make some builder and error handling things make more sense; it compiles again
push time in 3 hours
Pull request review commentunicode-org/message-format-wg
Add Literal Resolution section to formatting.md
when formatting a message for display in a user interface, or for some later pro The document is part of the MessageFormat 2.0 specification, the successor to ICU MessageFormat, henceforth called ICU MessageFormat 1.0. +## Literal Resolution++The resolved value of _text_, _literal_ and _nmtoken_ tokens+is always a string concatenation of its parts,+with escape sequences resolving to their escaped characters.+When a _literal_ or _nmtoken_ is used as an _expression_ argument+or on the right-hand side of an _option_,+the formatting function MUST treat their resolved values the same independently of their presentation,
Do errors count as "behavior"? It sounds like you're saying the error might be different based on the AST of the current expression, which suggests not treating resolved values the same independently of their presentation (to me, a different error is different behavior).
comment created time in 10 hours
Pull request review commentunicode-org/message-format-wg
Clarify that variables declarations may override previous ones
This local variable can then be used in other expressions within the same messag declaration = let s variable [s] "=" [s] expression ``` +Declaration examples:++```+let $foo = {|A literal value|}+```++```+let $foo = {:func opt=$bar}+```++```+let $foo = {$foo :number minimumFractionDigits=2}+```
@aphillips Fair point. However, I'd like it if there was some place to put an example like this:
let $foo = {|5|}
let $foo = {$foo :number minimumFractionDigits=2}
{{$foo}}
It would be useful for explaining the meaning of variable resolution if the example said: "If this message resolves to a string, the string is '5.00'." That would show that the $foo on the RHS on the second declaration is not the same as the $foo on the LHS.
Probably the syntax.md document isn't the place for that, since it doesn't show the resolved value of any of the examples.
Anyway, for illustrating the syntax, I'm OK with either or both.
comment created time in 5 days
Pull request review commentunicode-org/message-format-wg
Clarify that variables declarations may override previous ones
the successor to ICU MessageFormat, henceforth called ICU MessageFormat 1.0. ## Variable Resolution -To resolve the value of a Variable,-its Name is used to identify either a local variable,+To resolve the value of a _variable_,+its _name_ is used to identify either a local variable, or a variable defined elsewhere.-If a local variable and an externally defined one use the same name,-the local variable takes precedence. -It is an error for a local variable definition to-refer to a local variable that's defined after it in the message.+If more than one _declaration_ binds a value to the same _name_,+or if an externally defined variable and a _declaration_ use the same _name_,+the resolved value of the most recent _declaration_ preceding the _variable_ is used.
In an ideal world, this would say something like "variables are lexically scoped". That would obviate the need to talk about the "most recent declaration". However, explaining what "lexical scope" means for messages would mean explaining that:
let $v1 = $e1
let $v2 = $e2
match ...
desugars to:
let $v1 = $e1 in
let $v2 = $e2 in
match ...
and that external definitions of variables desugar to lets that enclose the message. I think that should be left for future work. I'm OK with merging the PR as-is; I think it's probably as precise as it's possible to get without mentioning lexical scope.
comment created time in 5 days
Pull request review commentunicode-org/message-format-wg
Clarify that variables declarations may override previous ones
the successor to ICU MessageFormat, henceforth called ICU MessageFormat 1.0. ## Variable Resolution -To resolve the value of a Variable,-its Name is used to identify either a local variable,+To resolve the value of a _variable_,+its _name_ is used to identify either a local variable, or a variable defined elsewhere.-If a local variable and an externally defined one use the same name,-the local variable takes precedence. -It is an error for a local variable definition to-refer to a local variable that's defined after it in the message.+If more than one _declaration_ binds a value to the same _name_,+or if an externally defined variable and a _declaration_ use the same _name_,+the resolved value of the most recent _declaration_ preceding the _variable_ is used.++A _declaration_ MAY overwrite the value of a _variable_ for later parts of the _message_.
A _declaration_ MAY override the value of a _variable_ for later parts of the _message_.
"Overwrite" connotes an imperative programming paradigm and we probably want to encourage people to think declaratively about messages.
comment created time in 5 days
Pull request review commentunicode-org/message-format-wg
Clarify that variables declarations may override previous ones
the successor to ICU MessageFormat, henceforth called ICU MessageFormat 1.0. ## Variable Resolution -To resolve the value of a Variable,-its Name is used to identify either a local variable,+To resolve the value of a _variable_,+its _name_ is used to identify either a local variable, or a variable defined elsewhere.-If a local variable and an externally defined one use the same name,-the local variable takes precedence. -It is an error for a local variable definition to-refer to a local variable that's defined after it in the message.+If more than one _declaration_ binds a value to the same _name_,+or if an externally defined variable and a _declaration_ use the same _name_,+the resolved value of the most recent _declaration_ preceding the _variable_ is used.
Note that there is already an open issue about whether to require eager or lazy evaluation of local variables:
https://github.com/unicode-org/message-format-wg/issues/299
Thta said, I don't think either version of the wording commits to either eager or lazy evaluation. It depends on the interpretation of the word "processed". "Processing" could mean evaluating (resolving?) the right-hand side of the declaration and binding the left-hand side to the resulting value, or it could mean binding the left-hand side to a thunk representing the right-hand side.
comment created time in 5 days
push eventcatamorphism/message-format-wg
commit sha 8668af2135feba3388a4dec86a64a45a01dd423a
Add newline Co-authored-by: Eemeli Aro <eemeli@gmail.com>
push time in 6 days
push eventcatamorphism/message-format-wg
commit sha 04bc82dba09a2d30ddb042481f1da55ae375adf0
Follow style for describing method return values Co-authored-by: Eemeli Aro <eemeli@gmail.com>
push time in 6 days
pull request commentunicode-org/message-format-wg
Clarifications to pattern selection
I re-requested review from @aphillips to confirm that it's OK for me to resolve the 3 open conversations, and re-requested from @eemeli for the sorting change that I made in response to the suggestion from @aphillips ( https://github.com/unicode-org/message-format-wg/pull/385/commits/f08b9b60a94321d17fb82b8e16d7ae3b63ae770a ), which seems significant enough to merit another look.
comment created time in 6 days
Pull request review commentunicode-org/message-format-wg
Clarifications to pattern selection
when * * {Otherwise} Presuming a more powerful implementation which supports selection on numerical values, and provides a `:plural` function that matches keys by their exact value as well as their plural category (preferring the former, if possible),-and an Enligh-language formatting context in which+and an English-language formatting context in which the variable reference `$count` resolves to the number `1`, pattern selection proceeds as follows for this message:
The edit could maybe be a separate PR?
comment created time in 6 days
push eventcatamorphism/message-format-wg
commit sha d1f2160ce1897e4b27d70a14e5417f8aaa43f92e
Update agenda.md
commit sha 37d421e4ce98756dded92dae588e9d37530a898e
Fix meeting date to be 2023-06-05 Nothing like being consistent...
commit sha 354115fc59e50fecfdb168913adbcf533db07b9b
Fix time link
commit sha 5aa988b44e61422c80c04137e94db914ed117404
Clarifications to pattern selection * State up front that the catch-all key `*` is never passed to the implementation-defined key-comparison method * Clarify the relationship between selector length and key length * Clarify the type signature for `SortVariants` * Fix typo
commit sha e2c61e261c76ab6338c4c2039fbb09a6f7e0a6bc
Remove reference to "the formatter" in description of catch-all matching Co-authored-by: Eemeli Aro <eemeli@gmail.com>
commit sha 919e1d4965f5ac803be3ab2223161464d9d56f9f
Change "decoded" to "resolved" for keys Change references to "the decoded value of a key" to "the resolved value of a key", and clarify that key resolution is the same as literal resolution
commit sha 81efa3ee8ee9bd3818902552c951113d61c4fa59
Clarify the relationship between key resolution and literal resolution Co-authored-by: Eemeli Aro <eemeli@gmail.com>
commit sha ade76a3657a588f12e8b9a53d549129fbf25e07d
Clarify the relationship between key resolution and literal resolution in all instances * Also remove up-front text explaining key resolution
commit sha 3cd09148db3f2672791d3a142f988b5ebc025deb
Normative language for required number of keys in variants Co-authored-by: Addison Phillips <addisonI18N@gmail.com>
commit sha f08b9b60a94321d17fb82b8e16d7ae3b63ae770a
Rewrite the call to `SortVariants` In the "Sort Variants" definition, re-specify the implementation-dependent `SortVariants` so as not to constraint whether it modifies the list in-place or returns a new list
push time in 6 days
Pull request review commentunicode-org/message-format-wg
Clarifications to pattern selection
Finally, sort the list of variants `vars` and select the _pattern_: The method SortVariants is determined by the implementation. It takes as an argument a `sortable` list of (integer, _variant_) tuples, which it modifies in place using some stable sorting algorithm.-The method does not return anything.+The method does not return a value: `sortable` is its out-parameter.
@aphillips The way the algorithm is currently written, sortable has to change on each iteration of the while loop. However, I think I've found a way to leave it open whether SortVariants modifies the list in-place and returns the same list as its result, or returns a new list. Let me know what you think.
comment created time in 6 days
push eventcatamorphism/message-format-wg
commit sha d925bf2437b5dbd1232081b32b44e766d8fe42ac
Normative language for required number of keys in variants Co-authored-by: Addison Phillips <addisonI18N@gmail.com>
push time in 6 days
Pull request review commentunicode-org/message-format-wg
Clarifications to pattern selection
the _pattern_ of one of the _variants_ must be selected for formatting. When a message has a single _selector_, an implementation-defined method compares each key to the _selector_ and determines which of the keys match, and in what order of preference.-A catch-all key will always match, but is always the least preferred choice.-During selection, the _variant_ with the best-matching key is selected.+The list of keys passed to this implementation-defined method+does not include the catch-all key `*`.+The catch-all key `*` is treated as a match for any _selector_,+but with the lowest possible preference.
@aphillips Yes, as Eemeli said, it's meant to be a clarification of what's already there. The existing definitions of "Resolve Preferences", "Filter Variants", and "Sort Variants" only pass literals to "the implementation-defined method". So the method can do whatever it wants if it's passed anything that's not a literal, such as *. Saying "The list of keys passed to this implementation-defined method does not include the catch-all key *" is another way of saying that these definitions don't rely on undefined behavior.
comment created time in 6 days
push eventcatamorphism/icu
commit sha 4bb29b5a6ba504d16614bb95ddd76a4474d32838
It compiles (and matches the putative design doc)
push time in 7 days
create barnchcatamorphism/icu
branch : parser-plus-data-model-plus-full-api
created branch time in 10 days
push eventcatamorphism/icu
commit sha e2e7e1cca00b997537b59d40b47aec8d0d3b13e2
Fixed reserved parsing bug; fixed some list things; tests pass now. (Tests don't check anything about the returned data model yet)
push time in 11 days
push eventcatamorphism/icu
commit sha 4f74594d545a03016dac9c6e96a305925a6c9863
Code compiles; test fails
push time in 11 days
push eventcatamorphism/message-format-wg
commit sha a6216b1987ab612d82040867138c47c61137d1e6
Clarify the relationship between key resolution and literal resolution in all instances * Also remove up-front text explaining key resolution
push time in 13 days
push eventcatamorphism/message-format-wg
commit sha 4147b6593bade5f9361479b1df4d1f79eabcb014
Clarify the relationship between key resolution and literal resolution Co-authored-by: Eemeli Aro <eemeli@gmail.com>
push time in 13 days
push eventcatamorphism/icu
commit sha 32cde73427a35a1c3f5639a5215f93403916a2a1
WIP (not compiling yet)
push time in 13 days
pull request commentunicode-org/message-format-wg
Clarifications to pattern selection
As per #384 I added another commit that changes references to "decoding" keys to "resolving" them. I'm not sure if the text I added is clear enough, but am open to suggestions. (Also, maybe this should land after #382 does, since it now refers to the "Literal Resolution" section that isn't there yet.)
comment created time in 13 days
push eventcatamorphism/message-format-wg
commit sha ba2f062bdebe571abcb1c2b33882f23d80e6c6ff
Change "decoded" to "resolved" for keys Change references to "the decoded value of a key" to "the resolved value of a key", and clarify that key resolution is the same as literal resolution
push time in 13 days