|Anonymous | Login | Signup for a new account||2015-06-30 07:21 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006480||OCaml||OCaml general||public||2014-07-07 20:05||2014-07-17 11:21|
|Target Version||Fixed in Version|
|Summary||0006480: Support short-cut extension nodes for field access|
|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.
|Attached Files|| dot-ext.patch [^] (583 bytes) 2014-07-07 20:05 [Show Content]
dot-ext2.patch [^] (1,188 bytes) 2014-07-07 21:24 [Show Content]
The second patch (dot-ext2.patch) includes support for field assignments. It converts:
x.%foo <- y
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.
be considered too verbose?
> 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 = ...]`.
> [%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.
(thanks dbuenzli for pointing me here)
I've discussed the use of [%js ...] here : https://github.com/ocsigen/js_of_ocaml/issues/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).
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
|2014-07-07 20:05||lpw25||New Issue|
|2014-07-07 20:05||lpw25||File Added: dot-ext.patch|
|2014-07-07 21:24||lpw25||File Added: dot-ext2.patch|
|2014-07-07 21:25||lpw25||Note Added: 0011792|
|2014-07-09 14:17||frisch||Note Added: 0011795|
|2014-07-09 14:50||lpw25||Note Added: 0011796|
|2014-07-10 00:27||drup||Note Added: 0011798|
|2014-07-16 16:12||doligez||Tag Attached: patch|
|2014-07-16 16:19||doligez||Status||new => acknowledged|
|2014-07-17 11:21||frisch||Note Added: 0011871|
|Copyright © 2000 - 2011 MantisBT Group|