Skip to content

Disallow .~ in extended indexing operators.#2106

Merged
damiendoligez merged 5 commits intoocaml:trunkfrom
yallop:dot-tilde
Oct 22, 2018
Merged

Disallow .~ in extended indexing operators.#2106
damiendoligez merged 5 commits intoocaml:trunkfrom
yallop:dot-tilde

Conversation

@yallop
Copy link
Copy Markdown
Member

@yallop yallop commented Oct 13, 2018

PR #1064 introduced support for user-defined indexing operators. The syntax is similar to the built-in operators (.(), .[], etc.) but with symbol characters between the dot and the delimiters, like this:

let (  .%( ) ) p (x,y) = p.(x).(y)
let (  .$?${ } ) p (x,y,z) = p.(x).(y).(z)
let (  .~[ ] <- ) p (x,y,z,t) v = p.(x).(y).(z).(t) <- v 

Unfortunately, allowing the sequence .~ is incompatible with MetaOCaml's longstanding splice syntax:

.~expression

Fortunately, there doesn't appear to be any code actually using .~ yet, so it's not too late to restore compatibility. The following table shows which user-defined indexing operators are currently in use by OCaml packages available via OPAM:

! $ % & ? @
owl !{} $() ${} %() %{} ?()
labltk ![] ![]
lablgtk ![]
reed-solomon %() %[] %{} %{} &{} &{}
orec %{}
phantom-algebra %[] %[] %() %()
pyml !$[] ![] %$[] %[] &() @$() @()
ocaml testsuite %() %() %[] %{} ?[] @() @[] @{}
ocamlformat testsuite %() %() %() %[] %[] %{} %{} ?[] @() @[] @{}

This PR removes ~ from the set of characters allowed in user-defined indexing operators, eliminating the incompatibility with MetaOCaml's syntax.

@gasche
Copy link
Copy Markdown
Member

gasche commented Oct 13, 2018

(cc @Octachron)

@Octachron
Copy link
Copy Markdown
Member

I am wondering if it would make sense to add .~ as a currently unused lexical token in order to reserve its use for MetaOcaml?

@yallop
Copy link
Copy Markdown
Member Author

yallop commented Oct 13, 2018

That's an interesting idea. 5122818 makes .~ a reserved sequence.

@yallop
Copy link
Copy Markdown
Member Author

yallop commented Oct 16, 2018

@Octachron, @gasche: would either of you like to review this? (I realise that it needs a Changes entry.)

Copy link
Copy Markdown
Member

@gasche gasche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation looks fine.

The feature looks very reasonable to me: it restricts a very-new feature that has apparently not been used in the wild yet (although it is part of a release OCaml version), I think the cost/benefit is reasonable.

@Octachron, extended operators are your expertise, so I will wait (not merge) to give you an opportunity to comment here. If you are against the change, I may have to reconsider.

@damiendoligez
Copy link
Copy Markdown
Member

You should document .~ as a keyword in the manual (chapter 7.1, lexical conventions).

Copy link
Copy Markdown
Member

@Octachron Octachron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think that the change is reasonable.

Another option might have be to just emit a DOTTILDE token if the dotop operator is.~ but removing ~ from the list of starting character for DOTOP is simpler. Moreover, it let MetaOcaml decides how to handle cases like .~!x .

Concerning the reserved error mechanism in the lexer, I have few remarks in term of explicitness, but it seems nice enough. (Initially, I was thinking of just importing the DOTTILDE token and the relevant lexer definition from the MetaOCaml patch; but the current implementation makes for a nicer error message. )

@yallop
Copy link
Copy Markdown
Member Author

yallop commented Oct 19, 2018

@damiendoligez:

You should document .~ as a keyword in the manual (chapter 7.1, lexical conventions).

Done (02cf280)

Copy link
Copy Markdown
Member

@gasche gasche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me if the CI passes.

@yallop
Copy link
Copy Markdown
Member Author

yallop commented Oct 22, 2018

The check-typo CI failure:

./manual/manual/refman/lex.etex:1.1: [missing-header] bad copyright header (first line)

looks spurious, since none of the etex files have copyright headers.

@dra27
Copy link
Copy Markdown
Member

dra27 commented Oct 22, 2018

This might be because of the recent changes to check-typo?

@damiendoligez
Copy link
Copy Markdown
Member

check-typo gets called explicitly on manual/manual/refman/lex.etex without regard for the typo.prune attribute on manual. The failure is completely unrelated to this PR, so I'm merging now.

@damiendoligez damiendoligez merged commit 20f4c6c into ocaml:trunk Oct 22, 2018
@gasche
Copy link
Copy Markdown
Member

gasche commented Oct 22, 2018

check-typo: This is a problem that is fixed in #1905 (still waiting for a review), and was noticed by @Armael who fixed it in an ad-hoc way for his own PR #2906 (I missed it). I just pushed 2713258 in trunk to fix it for good.

@yallop yallop deleted the dot-tilde branch October 22, 2018 15:18
damiendoligez pushed a commit to damiendoligez/ocaml that referenced this pull request Nov 5, 2018
Disallow .~ in the lexer to preserve MetaOCaml compatibility.
314eter added a commit to 314eter/tree-sitter-ocaml that referenced this pull request Jan 15, 2019
314eter added a commit to 314eter/tree-sitter-ocaml that referenced this pull request Jan 19, 2019
maxbrunsfeld pushed a commit to tree-sitter/tree-sitter-ocaml that referenced this pull request Feb 7, 2019
* Fix problems with character literals in comments

* Do not parse unclosed comments and quoted strings

* Update known failures

* Only allow line number directives with filename (ocaml/ocaml#931)

* Rename dot_operator to indexing_operator

* Disallow .~ in indexing operator (ocaml/ocaml#2106)

* Add test for indexing operator

* Support empty variants (ocaml/ocaml#1546)

* Support binding operators (ocaml/ocaml#1947)

* Use tree-sitter 0.14.0

* Cleanup trvis config
@gasche gasche mentioned this pull request Aug 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants