Skip to content

Clarify that variables declarations may override previous ones #381

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 10 additions & 6 deletions spec/formatting.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,14 +10,18 @@ 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 the left-hand side _variable_ of more than one _declaration_ uses 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 override the value of a _variable_ for later parts of the _message_.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that last time we proposed to not allow overriding.
Compared to programming, these messages are a relatively short "code block"
There should be no problem to just use a different name.
It just introduces complexity without any benefit that I can imagine.


Attempting to resolve a _variable_ with no preceding _declaration_ or external definition
binding a value to its _name_ results in an Unresolved Variable error.

## Error Handling

Expand Down
14 changes: 14 additions & 0 deletions spec/syntax.md
Original file line number Diff line number Diff line change
Expand Up @@ -275,6 +275,20 @@ 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}
```
Copy link
Collaborator

@catamorphism catamorphism May 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though it's explained in the formatting doc, is it worth explaining here as well that in the third example, either there must be a previous in-scope definition of foo, or this declaration is syntactically correct but semantically invalid?

Copy link
Member

@aphillips aphillips May 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A better example would make the second $foo into $bar or perhaps $someNumber, since the point of examples is to demonstrate the syntax.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


### Selectors

A `match` statement contains one or more **_selectors_**
Expand Down