Skip to content
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.

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

Term references with positional arguments? #293

Open
SirNickolas opened this issue Sep 17, 2019 · 1 comment
Open

Term references with positional arguments? #293

SirNickolas opened this issue Sep 17, 2019 · 1 comment
Labels

Comments

@SirNickolas
Copy link

-term = Term
    .attr = Attr

msg = {-term(0)}, {-term.attr(1)}.

When parameterized terms were introduced, @stasm wrote:

When calling a term, both positional and named arguments can be used, but positional are ignored, because, by their anonymous nature, they can't be looked up via variable names.

Shouldn’t a warning be emitted in such case?

By the way, how is it supposed to work, in the first place? Because that’s the point where official implementations diverge: JS and Rust silently ignore positionals while Python emits a warning and doesn’t even resolve positional arguments:

# "Invalid argument to NUMBER" in JS and Rust, "Ignored positional arguments" in Python.
test-0 = {-term(NUMBER("x"))}

# Called in JS and Rust, isn't in Python.
test-1 = {-term(FUNC-WITH-SIDE-EFFECTS())}
@Pike Pike added the resolver label Sep 17, 2019
@Pike
Copy link
Contributor

Pike commented Sep 17, 2019

Resolver behavior is unspecified, so different behavior between implementations is expected for now.

I just filed #294 to propose restrictions on what functions are expected to do.

Note, for our environment, we have a bug on file to warn about "silly terms" within the l10n toolchain, https://bugzilla.mozilla.org/show_bug.cgi?id=1529589.

I think it's much more impactful to do so in the l10n toolchain than in runtime behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants