[syntax] Order of variable/function in placeholder

[zbraniecki]

At the time when we were discussing different models of capturing placeholder formatter calls, there were two main "approaches":

1. { $count :number key=value }
2. { :number $count key=value }

Recent discussion and feedback from ICU TC follows the (1) path. I'm not sure how much of that is the bandwagon from MF1, vs conscious preference.

I'd like to make an argument for us to consider (2) as a superior syntactical choice.

If I understand correctly the syntactical narrative of (1) is that there is a variable (axiom) that can be optionally formatted by formatter :number with some optional arguments.

There are multiple limitations of that model:

a) There has to be a variable for any function to be called
b) There has to be exactly one variable
c) There is no clear way to compose calls

I'd like to argue that separately from whether we should implement those features, having a syntax that can, in the future, extend to them, is superior.

Particularly, I see the following potential future examples of uses:

a) Launch { :app_name variant="accusative" } // No variable
b) Showing appointments for { :date_range $start $end style="long" } // can be worked around with [$start, $end] syntax
c) You have { :number(:round($number)) } // I don't know how to express it cleanly in S-expr

Finally, I struggle to identify the advantages of (1) - either for today, or in form of future scaling options.

[eemeli]

A few comments about the future example uses:

a) The no-variable form is already supported by the syntax in #230, exactly as you have it there.
b) It's not necessarily as nice, but { $start $end :date_range style="long" } could also work.
c) In order to achieve chaining, it's possible to define local variables and use those as arguments. This has the same expressive power as a syntax that does so in a single placeholder, while making it more clear how e.g. options are assigned.

I'm explicitly not arguing here for one choice over another, as I think either could work and support an LL(1) parser.

[stasm]

The mindset that helped me come round on this was to think of formatters as methods invoked on the argument. I remember we even discussed something like {$count.number} and {$count:number} as potential syntax, with no whitespace, to make it look like a method call.

This way, it puts more emphasis on the argument, which is nice semantically, but also important practically: many CAT tools will abbreviate the entire placeholder like {$count :number maxFractionDigits=2} to a chip-like UI widget with a $count label on it.

[zbraniecki]

The mindset that helped me come round on this was to think of formatters as methods invoked on the argument.

That's what I tried to capture as a narrative that I see for (1). My concern is that it corners functions to be formatters - after all if there's no variable, the formatter makes no sense.

Which I think is a limiting mental model. I can see cases (and Eemeli pointed out that they're now supported) when a function is not a formatter.
If the syntax indicates that it is, but allows for it not to be, that's a bit confusing.
It feels a bit as if we did let x = 1; but also then allowed let 1;. The (2) is more suited for that duality :number $count and :standalone and $count all "feel" reasonable.

I agree that if a) standalone is supported, b) multivariable can work either via $ vs : or via [] sigils and some composition is possible in the (1) model then my concern is degraded to perceived DX, rather than hard limitations.

That, in result, is subjective, and I will not oppose if the group decides that (1) is a better option, but I would like to see it explicitly decided, rather than implicitly adopted.

[aphillips]

My concern is that it corners functions to be formatters

It corners formatters to be functions, but it doesn't say that there can't be other functions. I think of selectors as functions also, but they are not formatters. For example, plurals evaluate a parameter ($count.plural) without formatting the value.

[mihnita]

At least for me the reasoning is that when I compose a message the important part is WHAT is formatted, not its type.

When you read the message, you think pageNumber / totalPages, not number / number.
That is the important thing, and comes first.
So it was a conscious decision for the ME proposal.

Also, if we look at what is a more common use, $foo without function (with the function implied by the type), or a function without an argument, I would think the first case is more common.
In fact I can't even think of good functions without argument for formatters, only for selectors.

---

Otherwise, both options seem identical in power / expressivity.
They now have sigils, so they can be easily identified.
I don't see how one can argue that function-parameter can do things that parameter-function can't do.

[echeran]

All of the other comments here are good, and I pretty much agree with them.

At least for me the reasoning is that when I compose a message the important part is WHAT is formatted, not its type.
... That is the important thing, and comes first. So it was a conscious decision for the ME proposal.

Also, if we look at what is a more common use, $foo without function (with the function implied by the type), or a function without an argument, I would think the first case is more common. In fact I can't even think of good functions without argument for formatters, only for selectors.

Otherwise, both options seem identical in power / expressivity. They now have sigils, so they can be easily identified. I don't see how one can argue that function-parameter can do things that parameter-function can't do.

Yes, this is was the discussion during the EM proposal. Back then, I started out in favor of what @zbraniecki is arguing for -- option 2, which is a function-first / prefix notation -- and preferring that over option 1 which is like the Algol/C++ style syntax that you often see in programming languages, especially with OOPy languages. When we are specifically talking about the specific context of a general purpose programming language, I wholeheartedly agree with @zbraniecki's earlier assertions (there are reasons).

However for MessageFormat, as @mihnita said, it's a formatting API. You can have a option-less placeholders that have just the argument ({$name}) and potentially option-less placeholders for function calls ({:currentTime}). The argument that won me over is that a formatting API will care more about what things (the arguments) it is interpolating into the output than how -- I think this is what @stasm 's comment gets at. And as evidence of that assertion, you will see things like {$name} more often than {:currentTime}. The fact that it looks OOPy or Algol/C++-ish and is therefore more visually familiar to more people than prefix-notation S-expressions is a side effect that is less compelling, but maybe helps some, FWIW. Ultimately, I don't mind much either way.

[zbraniecki]

Thank you all!

I see the consensus emerging toward (1), with resolution of my concerns as:

a) There has to be a variable for any function to be called

There does not have to be. {:currentTime} is acceptable and looks reasonable, even if the switch from {$time :currentTime} -> {:currentTime} may feel slightly less familiar to people used to EXCEL etc.

b) There has to be exactly one variable

There does not. { $start $end :date_range style="long" } is an acceptable format for multi-parameter formatter calls.

c) There is no clear way to compose calls

It is possible to assign local variables as functions and then use them as arguments to another formatter. We even prefer that over traditional composition.

==

Thank you all. I consider this topic resolved unless new arguments show up. We can then reopen.

[echeran]

There does not have to be. {:currentTime} is acceptable and looks reasonable, even if the switch from {$time :currentTime} -> {:currentTime} may feel slightly less familiar to people used to EXCEL etc.

We will probably want to assume that any function is returning a formatted object. Otherwise, it will complicate things to define functions like this of no arguments on how to dispatch to the correct formatter, whether for input to selection or just formatting alone.

b) There has to be exactly one variable

There does not. { $start $end :date_range style="long" } is an acceptable format for multi-parameter formatter calls.

Oh, hmm, I missed this implication. This is a case where it would make sense to just have 1 argument, like {$range :date_range style="long"}. I think we may have discussed in the committee meetings the same topic and the committee may have said the same thing -- just use 1 argument for a function. I don't remember the reasoning, but for me personally, I think $range instead of having both $start and $end is an argument in favor of named arguments instead of positional arguments (the fields of a struct / object / map / bag input are the names). And it simplifies the syntax. And to @stasm 's point above, a UI widget in a UI for translators representing the placeholder that says [range] would have been easy to label, but would be less obvious when there are 2+ args.