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.

Sign up for GitHub

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

Clarify that variables declarations may override previous ones #381

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1fa0e1d
Allow for local variable overrides
eemeli May 17, 2023
32767f9
Rewrite based on code review comments
eemeli May 31, 2023
0ea4510
Update spec/formatting.md
eemeli Jun 1, 2023
4548843
Avoid the terms "binds"
eemeli Jun 19, 2023
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
View file
Open in desktop
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 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.
Copy link
Member

Choose a reason for hiding this comment

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

Should we also state that selectors and other post-declaration expressions can't modify a value (no non-declaration side-effects)?

I would suggest a slight wording change to make it easier (for me) to parse:

Suggested change
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.
Each _declaration_ is processed sequentially: when a _declaration_ binds a value to a _name_ used in a previous _declaration_ or in an externally defined _variable_,
the resolved value of the most recent _declaration_ preceding the _variable_ is used.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think the function purity / lack of side effects ought to be addressed with respect to function resolution, rather than here.

The proposed "is processed sequentially" statement is a bit problematic, as it may be interpreted to require and enforce an eager processing model. Consider this message:

let $foo = {:really-heavy-operation}
match {$bar}
when 0 {Nothing here}
when * {Have a {$foo}}

In this case, we should make sure that in the bar == 0 case an implementation is not required to determine and then throw away the value of $foo.

Copy link
Collaborator

@catamorphism catamorphism Jun 1, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Note that there is already an open issue about whether to require eager or lazy evaluation of local variables: #299

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

@eemeli I don't think we have to say anything about early or late binding of variables: we should not require early binding but we should not require late binding either. It's an implementation detail. What is important is that declarations behave as if they were evaluated in order.

I think we can let the text go in as-is and revisit.


A _declaration_ MAY overwrite the value of a _variable_ for later parts of the _message_.

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
View file
Open in desktop
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 •
edited
Loading

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 •
edited
Loading

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