Here's an alternative proposal with immutable variables that I think could work. I think someone else may have previously proposed something like this, but I can't find that source right away.

Let us introduce a new keyword input that allows for the annotation of external variables. It works like this:

input {$count :number}
input {$date :datetime dateStyle=long}
match {$count}
when 1 {You received one message on {$date}}
when * {You received {$count} messages on {$date}}

This effectively replaces the current "hack" of saying let $foo = {$foo ...}, and provides a way to explicitly declare that a variable is non-local: input {$bar} doesn't require an annotation.

At the syntax/data model level, input or let declarations would not be required for all selectors and placeholders, but a user-configured validator could of course be stricter.

In the ABNF the change would look like this:

message = [s] *(input-annotation [s]) *(declaration [s]) body [s]

input-annotation = input [s] "{" [s] operand [s annotation] [s] "}"
input = %x69.6E.70.75.74  ; "input"

The expression rule can't be used here directly because the operand is required.

With this in place, I would support prohibiting re-assignment/shadowing, as long as a local let declaration would take precedence and not cause an error if a similarly named external variable is passed to the formatter without a corresponding input declaration in the message.

The use case of chaining operations on a variable with a single name is not supported here, and the $foo1, $foo2 $foo3 sorts of names would be required for that.

One observation I do have is that if our variables are immutable, then we should be able to reorder local variable declarations exactly like we allow for when variants to be reordered. We do still need to prohibit referential loops, but that doesn't require the declarations to be in any specific order.

Here's an alternative proposal with immutable variables that I think could work. I think someone else may have previously proposed something like this, but I can't find that source right away.

I think this is an interesting proposal. I am not sure that I'm excited about it, although it does solve annotation of external values.

One observation I do have is that if our variables are immutable, then we should be able to reorder local variable declarations exactly like we allow for when variants to be reordered. We do still need to prohibit referential loops, but that doesn't require the declarations to be in any specific order.

This would bring back shadowing concerns, though, wouldn't it?

For inputs a=1;b=2;c=3 what do these print:

let $c = {$b}
let $b = {$a}
{a={$a} b={$b} c={$c}}

let $b = {$a}
let $c = {$b}
{a={$a} b={$b} c={$c}}

Here's an alternative proposal with immutable variables that I think could work. I think someone else may have previously proposed something like this, but I can't find that source right away.

We briefly discussed defining input variables in #403 (comment). The, in #310 (comment) @aphillips suggested the modify keyword which would avoid the need of reassignment.

I quite like the idea of input {$count :number} because it cleverly address one of the most common existing use-cases for local variables (decorating input variables) without introducing local variables.

Earlier in the thread, @eemeli commented on proposed syntax for local variables:

These are all pretty ugly, but I presume that's intentional. Do we not want users to use local variables? Because that's what we're saying by making them ugly and clumsy.

Maybe we actually don't want local variables to be common, especially if there's a convenient and dedicated solution to annotate input variables (like the input ... syntax). What are the use-cases for local variables that are not transformed input variables? I can think of a few:

• Transforming input variables in a way that prevents access to the original value. Most formatters can be implemented in a "lazy" way that makes it possible to access the raw original value. However, I can imagine some formatters don't, although it can be argued that the following example is overly complex and contrived.

  let $firstUser = {$guests :list.take count=1}
  let $tailCount = {$guests :list.length offset=1}
  
  {{$firstUser} and ${tailCount} other people like this.}
  

• Factoring out literals with their formatting options to avoid repetition across multiple variants. A synthetic example:

  let $epoch = {0 :datetime weekday=long}
  match {$count}
  when 1 {{$epoch} one.}
  when * {{$epoch} many.}
  

  I note, however, that perhaps we should consider how badly we want to avoid repetition in such cases. After all, top-level variants do cause repetition of translations anyways, by design.

• Factoring out markup to avoid repetition across multiple variants.

  let $openBold = {bold +html opt=val}
  match {$count}
  when 1 {{$openBold}strong{bold -html}}
  when * {{$openBold}strong{bold -html}}
  

  I think this is underspecified in the current design of open/close elements (Exploration: sigils inside expressions #448), and I'm not sure if it should be allowed. Same as above, perhaps repetition isn't actually that bad? We're OK with repeating text content in all variants — why not markup?

One observation I do have is that if our variables are immutable, then we should be able to reorder local variable declarations exactly like we allow for when variants to be reordered. We do still need to prohibit referential loops, but that doesn't require the declarations to be in any specific order.

This would bring back shadowing concerns, though, wouldn't it?

Not really, because each $var would get looked up by a well defined method:

1. If there's an input statement for $var, find the corresponding var value in the inputs and apply the annotation to it.
2. Else, if there's a let $var statement, use its value.
3. Else, find the corresponding var value in the inputs.
4. Else, complain with Unresolved Variable.

So if the value gets determined in step 2, the corresponding input is ignored.

For inputs a=1;b=2;c=3 what do these print:

let $c = {$b}
let $b = {$a}
{a={$a} b={$b} c={$c}}

let $b = {$a}
let $c = {$b}
{a={$a} b={$b} c={$c}}

With logic as defined above, both of those would end up formatting as a=1 b=1 c=1.

@eemeli noted:

Not really, because each $var would get looked up by a well defined method:

I think I'm still worried about the conceptual simplicity element of this. For example, would this be technically allowed?

input {$a :whatever}
let $a = {$b}
...

I put the reordered examples because people might make mistakes based on thinking of the lines as being executed in order.

@stasm noted:

I quite like the idea of input {$count :number} because it cleverly address one of the most common existing use-cases for local variables (decorating input variables) without introducing local variables

I wasn't keen on input previously because the way it was originally suggested was to require it before using the variable (that is, variables had to be declared before use). This seems onerous when all I really want is {Hello {$user}}. Our syntax should be easy to use (at least in the common cases). But I agree with you that it helps give us an out for modifying values without allocating local variables.

Stepping back: does everyone agree with the matrix of options in the document? Are there other options we want to consider? Comparing the options and weighting our reasons behind those choices seems useful