-
Notifications
You must be signed in to change notification settings - Fork 222
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
Ambiguous syntax in nested function calls. #334
Comments
I was also thinking on the same, sometimes we create variables only because the expression-building capacities are not flexible enough. Some thoughts:
The same separator could be used to terminate the new in-place poetic literals within an expression, so they would not last until the end of the statement.
These two could even be mixed:
|
Seems good to me. |
Consider:
At a purely grammatical level, this syntax is ambiguous between:
x = sum(product(a,b), product(c,d))
x = sum(product(a,b,product(c,d))
x = sum(product(a,b,product(c),d)
x = sum(product(a), b, product(c), d)
One solution here is define the grammar in terms of functions with specific parameter counts, so the parser knows that
product
takes exactly two arguments and disambiguates accordingly. (This would mean explicitly supporting zero args, one arg, two args, three args, and so on, so we'd need to decide an arbitrary upper limit for the maximum number of arguments a program can take, and default/optional arguments orparams
style arguments-as-a-list would never be supported.)Another solution would be to prohibit function calls inside function calls. I don't like that.
A third solution would be to use another character - the semi-colon
;
, say - to denote the end of an argument list:I'm favouring the third option here - and I suspect there might be other scenarios (nested lists?) where this syntax proved useful.
Thoughts?
The text was updated successfully, but these errors were encountered: