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

Ambiguous syntax in nested function calls. #334

Open
dylanbeattie opened this issue Mar 24, 2024 · 2 comments
Open

Ambiguous syntax in nested function calls. #334

dylanbeattie opened this issue Mar 24, 2024 · 2 comments
Milestone

Comments

@dylanbeattie
Copy link
Collaborator

Consider:

X is sum taking product taking a, b, product taking c, d.

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 or params 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:

sum taking product taking a; b, product taking c, d.
(equivalent to sum(product(a), b, product(c,d))

sum taking product taking a, b; product taking c; d.
(equivalent to sum(product(a,b), product(c), d)

sum taking product taking a, b, product taking c; d
(equivalent to sum(product(a,b,product(c),d)

I'm favouring the third option here - and I suspect there might be other scenarios (nested lists?) where this syntax proved useful.

Thoughts?

@dylanbeattie dylanbeattie added this to the 2.0 milestone Mar 24, 2024
@gaborsch
Copy link

I was also thinking on the same, sometimes we create variables only because the expression-building capacities are not flexible enough.

Some thoughts:
We might need to use double (triple) semicolons, if three or more function calls are embedded, the syntax should allow this somehow.

sum taking product taking A sum taking B, C;; D
(equivalent to sum (product(A, sum(B, C))), D  = (A*(B+C))+D )

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.

sum taking like a mouse; like an elephant
(Equivalent to sum taking 15, 28)

These two could even be mixed:

sum taking product taking A like a thunder;; B
(equivalent to sum(product(A, 17), B) )

@caseyc37
Copy link

Cast like the humanitarian; into emptiness

Seems good to me.

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

No branches or pull requests

3 participants