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
Support "obj # (meth arg1 ... argn)" #6782
Comments
Comment author: @lpw25
I don't think I have any alternative suggestions (other than leave things as they are), but I have to say that I really dislike that syntax. |
Comment author: @damiendoligez A location with mismatched parentheses? That's asking for trouble, don't do that. Other than that, the feature seems reasonable. |
Comment author: @garrigue The only solution I see would be to introduce a new infix pseudo-operator. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
For info, eventually we got rid of this syntax at LexiFi, and it was not used much. |
Original bug ID: 6782
Reporter: @alainfrisch
Status: acknowledged (set by @damiendoligez on 2015-02-18T22:57:54Z)
Resolution: open
Priority: normal
Severity: feature
Category: lexing and parsing
Monitored by: @yallop @hcarty
Bug description
Since method call binds more tightly than function application, it is inconvenient to chain method calls with arguments:
(((f x0) # m1 x1) # m2 x2) # m3 x3
which would be written "f(x0).m1(x1).m2(x2).m3(x3)" in many other languages.
We have been using the following syntactic variant at LexiFi for some time:
(f x0) # (m1 x1) # (m2 x2) # (m3 x3)
and I'd like to propose it for upstream inclusion.
This can be implemented by one extra rule in parser.mly:
| simple_expr SHARP LPAREN method_label simple_labeled_expr_list RPAREN
{ mkexp (Pexp_apply(mkexp(Pexp_send($1, $4)), List.rev $5)) }
(or perhaps some extra work so that the location of the Pexp_send node covers only "obj # (meth").
One counterargument is that it's a new use of parentheses, and they don't even correspond to an actual subtree of the AST. But I don't see a better syntax.
Note: #6583 is a proposal to let js_of_ocaml's new ppx support use the syntax "obj ## meth arg" for Javascript method invocation, and in Javascript, chaining method calls is quite common. The proposal is to consider ## as a custom operator, which means that "obj ## (meth arg)" could already be supported by the ppx, and Drup told me that he indeed plans to do so. Keeping the syntactic similarity between calls of Javascript methods and normal methods calls in OCaml is an extra argument for the present proposal about "obj # (meth arg)".
The text was updated successfully, but these errors were encountered: