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
Comments
Comment author: @lpw25 The second patch (dot-ext2.patch) includes support for field assignments. It converts:
into:
|
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? |
Comment author: @lpw25
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.
Yes I'm not particularly happy with this either. Perhaps a different encoding, like:
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
I think that the |
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.
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.
I would actually have several use cases for that, so it might be a good idea.
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). |
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 "%."] ....
|
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. |
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:using the current js_of_ocaml syntax, could be replaced by:
which would be a short-cut syntax for:
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
The text was updated successfully, but these errors were encountered: