Change named arguments syntax to $name = value

[stasm]

This idea hit me when I was working on #176 (comment). It's long bothered me that we use colons : to define values of named arguments. It's different from how the values of messages, terms and attributes are defined.

The reason to use : was to avoid ambiguity with definitions of new messages. This was particularly important in context of the indentation relaxation (#87), where a named argument formatted over multiple lines could produce a false positive for the error recovery:

# Made-up syntax. We couldn't use = for named args because
# in case of a syntax error the error recovery algorithm would 
# see month = as a beginning of a new message.
err-call-expr = {DATETIME($date,
month = "long"

If all named arguments were required to start with the $ sigil, there would be no ambiguity. It also makes sense semantically: named arguments define values of variables used by the function. And we could use the familiar = for defining the values.

# Syntax 0.7
today-is = Today is {DATETIME($date, month: "long", year: "numeric", day: "numeric")}

# This proposal
today-is = Today is {DATETIME($date, $month="long", $year="numeric", $day="numeric")}

[hkasemir]

This one leaves me a touch confused, and ultimately I prefer the old syntax, but this might just be because it parallels javascript so well.

my reactions:

• I like the use of : because it mirrors how we would expect to define it via the js Date, so it feels intuitive
• I have mixed feelings about defining every variable with the $ - it makes sense to me that this would define user supplied variables from the source (in React, <Localized id="foo" $count={5}>, but when it comes to the arguments that are only specified in the FTL for the benefit of the DATETIME function, it seems less necessary. The part that I'm conflicted about is that I do recognize that it could simplify things to make all variables regardless of whether they are defined in the FTL or in the front-end code require the sigil.

So ultimately, I prefer the current syntax, but I recognize that the new one could solve problems I haven't dug into.

[stasm]

Thanks for sharing your thoughts, @hkasemir. I understand the internal conflict you're describing. Whenever I write JS and then go back to Fluent, I don't find : too bad. But then I spent the entire day writing and reviewing Python today, and my fingers are quick to type =. I think it's OK for Fluent to be influenced by other programming languages, but it also should stay agnostic as much as it can. I hope Fluent can be used with many different programming environments. JS is just a start :)

The reason why I've suggested changing the syntax to = is that it's already used in other places in the syntax. By removing : we'd simplify the sigil space of the syntax. One sigil fewer to learn.

To your second point, yes, this would effectively change the meaning of $ from this comes from the developer to this is any kind of variable. I think this would make the most sense if #176 is accepted, because parameterized terms add a whole new dimension to variables. In that proposal, -brand-name($case="nominative") would evaluate -brand-name with the given value of the local $case variable.

[hkasemir]

cool, sounds good! Those are good points, and I think after just a little mental re-framing, it's easy to see the benefits of this simplification.

[Pike]

This sounds like something rather tough to implement for the python parser, is there enough to gain?

[stasm]

Yes, the simplification of the syntax is worth the extra effort. Especially with #176, requiring the $ sigil in argument names will result in consistency in syntax between the caller and the callee.

Looking at the Python parser, to keep the backwards compat for the archaeology use-case we'd need to first check for MessageReference or VariableReference here, and then expect : or =, respectively.

I would also like to point out that there's only one string in gecko-strings which would be affected by this change.

[stasm]

Moving this out of the Syntax 0.8 milestone, which shipped in mid-December. I'm keeping this issue open for now to make it easier to find in case it's relevant to people testing Syntax 0.8.