Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006480OCamlOCaml generalpublic2014-07-07 20:052014-07-17 11:21
Reporterlpw25 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version4.02.0+dev 
Target VersionFixed in Version 
Summary0006480: Support short-cut extension nodes for field access
DescriptionFor 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.
Tagspatch
Attached Filespatch file icon dot-ext.patch [^] (583 bytes) 2014-07-07 20:05 [Show Content]
patch file icon dot-ext2.patch [^] (1,188 bytes) 2014-07-07 21:24 [Show Content]

- Relationships

-  Notes
(0011792)
lpw25 (developer)
2014-07-07 21:25

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

    x.%foo <- y

into:

    [%.foo<- x;;y]
(0011795)
frisch (developer)
2014-07-09 14:17

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?
(0011796)
lpw25 (developer)
2014-07-09 14:50

> 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.
(0011798)
drup (reporter)
2014-07-10 00:27

(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).
(0011871)
frisch (developer)
2014-07-17 11:21

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

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker