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

Support short-cut extension nodes for field access #6480

Closed
vicuna opened this issue Jul 7, 2014 · 6 comments
Closed

Support short-cut extension nodes for field access #6480

vicuna opened this issue Jul 7, 2014 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Jul 7, 2014

Original bug ID: 6480
Reporter: @lpw25
Status: acknowledged (set by @damiendoligez on 2014-07-16T14:19:08Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.02.0+dev
Category: language features
Tags: patch
Monitored by: @Drup @hcarty

Bug description

For some syntax extensions (e.g. js_of_ocaml's ## syntax) it would be useful to provide a short-cut syntax for extension nodes of field accesses. For example:

window##document##createElement (Js.string "span")

using the current js_of_ocaml syntax, could be replaced by:

window.%document.%createElement (Js.string "span")

which would be a short-cut syntax for:

[%.createElement [%.document window]] (Js.string "span")

Of course, such syntax extensions could instead be implemented by recognising an existing operator and treating it specially in a -ppx transformer. However I think it would be better to have such field access extensions clearly marked as extensions rather than re-purposing existing syntax.

The attached patch implements this proposal. Ideally, if we do add this feature, it should go in 4.02.

File attachments

@vicuna
Copy link
Author

vicuna commented Jul 7, 2014

Comment author: @lpw25

The second patch (dot-ext2.patch) includes support for field assignments. It converts:

x.%foo <- y

into:

[%.foo<- x;;y]

@vicuna
Copy link
Author

vicuna commented Jul 9, 2014

Comment author: @alainfrisch

I can see the use of the proposal, but it seems ad hoc in that it "extends" two specific syntactic forms (why not others?). Also its use of the id of the extension node is somewhat unexpected: the id is supposed to identify the extension itself (which processing to apply to the sub-term), but here it is used more like a payload.

Would

[%js window.document.createElement]

be considered too verbose?

@vicuna
Copy link
Author

vicuna commented Jul 9, 2014

Comment author: @lpw25

I can see the use of the proposal, but it seems ad hoc in that it "extends" two specific syntactic forms (why not others?)

I was picturing it as just an extension to the existing handling of things like "let%foo". I agree it is better if there is a clear criteria for which syntaxes have a short-cut version. The current one is basically that "keywords" have short-cuts. Perhaps "keywords and separators" would also be a reasonable criteria.

Also its use of the id of the extension node is somewhat unexpected: the id is supposed to identify the extension itself (which processing to apply to the sub-term), but here it is used more like a payload.

Yes I'm not particularly happy with this either. Perhaps a different encoding, like:

for.%bar    =>     [%dot [%bar foo]]

Or maybe the extension nodes should keep some information about which syntax they came from. This could also be useful if people want to write extensions which work for let%foo x = ... but not [%foo let x = ...].

Would

[%js window.document.createElement]

be considered too verbose?

I think that the ## is used quite heavily in js_of_ocaml code, so this might become pretty verbose.

@vicuna
Copy link
Author

vicuna commented Jul 9, 2014

Comment author: @Drup

(thanks dbuenzli for pointing me here)

I've discussed the use of [%js ...] here : ocsigen/js_of_ocaml#144 and my opinion is still the same: it breaks regular records (or regular objects, with #), which is annoying.

The issue I see with this proposal is that if two ppx want to use these "special fields" they will conflicts, and there is no alternate syntax to work around it.

In the github issue linked, I proposed to extend slightly the ocaml parser and let ppxs use the new operators. Both solutions seems equally ad-hoc to me.

Yes I'm not particularly happy with this either. Perhaps a different encoding, like:
for.%bar => [%dot [%bar foo]]

The issue I see with that is that js fields can be anything, including a bar that is already used by another ppx. If the other ppx loads first and desugarize bar, it's going to break (and the error is probably going to be hard to decipher). Using "%.bar" is a bit more robust.

Or maybe the extension nodes should keep some information about which syntax they came from. This could also be useful if people want to write extensions which work for let%foo x = ... but not [%foo let x = ...].

I would actually have several use cases for that, so it might be a good idea.

I think that the ## is used quite heavily in js_of_ocaml code, so this might become pretty verbose.

Indeed. It's too verbose. If I had to choose a solution right now, I would cheat by using the % operator (as proposed by alain frisch) but I would prefer not to do that and use at least something like this proposal (or something better).

@vicuna
Copy link
Author

vicuna commented Jul 17, 2014

Comment author: @alainfrisch

Another proposal: let's use existing infix operators, but letting the users pick which specific operator to use with a global (per unit) configuration.

[%%js config dot "%."]

....

foo %. bar

@github-actions
Copy link

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.

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

No branches or pull requests

1 participant