Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

FTL Proposal: Flatten nested selectors

30 views
Skip to first unread message

zbran...@mozilla.com

unread,
Dec 16, 2016, 5:15:38 AM12/16/16
to mozilla-t...@lists.mozilla.org
n the thread about bi-annual syntax review, I listed a number of potential problems with the syntax.

In this proposal, I'd like to tackle mainly problem (6).

Summary:

I suggest that we allow for range of selectors to be grouped.
The solution to the example provided in the problem statement would look like this:

key = { $num, $gender ->
[one, masculine] She likes when he dances
[one, feminine] She likes when she dances
[other, masculine] They like when he dances
[other, feminine] They like when she dances
}

It requires small changes to the AST and syntax, since we already support lists ("key = { $user1, $user2 }") and we only would need to allow a selector expression to be a list and keyword key to be a list.

The value is the simplification of the visual clutter.

Additionally, this solution would play nicely with the proposal to allow for specifiers (the "Dissolve traits" proposal, part 1):

key2 = { key[one, masculine] }

working for both, nested and flattened nested selectors.

Thoughts?
zb.

Staś Małolepszy

unread,
Dec 16, 2016, 8:26:00 AM12/16/16
to Braniecki, Zbigniew, mozilla-t...@lists.mozilla.org
On Fri, Dec 16, 2016 at 11:15 AM, <zbran...@mozilla.com> wrote:
> I suggest that we allow for range of selectors to be grouped.

I support this change although I have comments about the syntax below.
If we find a solution to address the comments, this proposal would
offer a convenient sugar for a use-case for which we want to encourage
a good practice.

> key = { $num, $gender ->
> [one, masculine] She likes when he dances
> [one, feminine] She likes when she dances
> [other, masculine] They like when he dances
> [other, feminine] They like when she dances
> }
>
> It requires small changes to the AST and syntax, since we already support lists ("key = { $user1, $user2 }") and we only would need to allow a selector expression to be a list and keyword key to be a list.

We need to decide what the operator precedence of ',' and '->' is. If
the comma binds tighter then the current syntax does not allow to
build a list formatted via Intl.ListFormat with a select expression as
one of its elements. OTOH, if the arrow binds tighter, the example
above will only use $gender as the selector.

To remove the ambiguity, we could (a) introduce parentheses for
selector grouping. { foo, (bar, baz) -> ... } or maybe { foo, [bar,
baz] -> ... } to make it consistent with the syntax for keywords.
Perhaps the meaning of [ ] could be changed to denote tuples.

Alternatively, we could (b) introduce parens for grouping expressions:
{ foo, (bar, baz -> ...) }. This would have the benefit of also being
unambiguous for trailing elements: { foo, (bar, baz -> ...), qux }
which is hard to achieve in (a). While { foo, (bar, baz) -> ..., qux
} may look feasible keep in mind that there are newline breaks hiding
behind that ... . A more appropriate example would need to be:

{ foo, (bar, baz) ->
[one, one] One bar, one baz.
[other, other] Many bars, many bazes.
, qux }

^-- this comma here is required to end the (bar, baz) -> ... select
expression.

Another solution (c) is a workaround that's possible right now: use
another Pattern with a placeable: { foo, "{ bar, baz -> .. }", qux }.
I'd consider this a hack around a shortcoming of the current syntax
design. If we're making changes, let's fix this one too.

My last idea (d) is to remove the implicit list syntax, i.e. { foo,
bar } being equal to { LIST(foo, bar) }. I wouldn't mind simplifying
the AST of placeables and making them single-valued. I assume lists
will be rare and calling the LIST builtin would improve the
readability by being more explicit. This would allow using { and }
for grouping, like so: { LIST(foo, { bar, baz -> ... }, qux) }. { and
} could be

My current vote goes to (d) as it doesn't introduce any new syntax
tokens and manages to simplify the AST for placeables. I'm curious to
hear what you think!

-stas

Staś Małolepszy

unread,
Dec 16, 2016, 8:40:33 AM12/16/16
to Braniecki, Zbigniew, mozilla-t...@lists.mozilla.org
Sent a bit too early! Below is the missing part.

On Fri, Dec 16, 2016 at 2:25 PM, Staś Małolepszy <st...@mozilla.com> wrote:
> My last idea (d) is to remove the implicit list syntax, i.e. { foo,
> bar } being equal to { LIST(foo, bar) }. I wouldn't mind simplifying
> the AST of placeables and making them single-valued. I assume lists
> will be rare and calling the LIST builtin would improve the
> readability by being more explicit. This would allow using { and }
> for grouping, like so: { LIST(foo, { bar, baz -> ... }, qux) }. { and
> } could be

{ and } could be nested many times if needed: { foo } would be the
same as {{ foo }} or even {{{ foo }}}. I wouldn't advertise this as a
feature, just like I don't write my JS with (((1+2))) parens around
everything :) We could also disallow Placeables in other Placeables
making {{ foo }} not legal, and only allow for Placeables in Patterns
and as arguments to CallExpressions: "Foo { bar } Baz" and { LIST({
foo -> ... }) }.

zbran...@mozilla.com

unread,
Dec 17, 2016, 5:04:52 AM12/17/16
to mozilla-t...@lists.mozilla.org
I'm happy to consider dropping implicit lists for now. I agree that they are a rare case which can be perfectly served with an explicit function.

If in the future we'll start seeing it being used more, we can always revisit this and add the implicit lists with any related syntax that will allow for operator precedence matrix.

In the future I believe we will want to allow array valued variables, like:

key = { LIST($users) }

or

msg = { PLURAL($nums, type: "range") ->
[one]
[other]
}

zb.

Staś Małolepszy

unread,
Dec 20, 2016, 11:35:40 AM12/20/16
to Braniecki, Zbigniew, mozilla-t...@lists.mozilla.org
On Sat, Dec 17, 2016 at 11:04 AM, <zbran...@mozilla.com> wrote:

> In the future I believe we will want to allow array valued variables, like:
>
> key = { LIST($users) }

That's already possible! Both { LIST($users) } and { $users } work
right now. This is consistent with { $num } and { NUMBER($num) } etc.
0 new messages