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

Sanitize the ternary operator and question mark parsing situation (deprecations only) #22712

Closed
wants to merge 4 commits into from

Conversation

carlobaldassi
Copy link
Member

@carlobaldassi carlobaldassi commented Jul 8, 2017

These are 2, mostly independent, commits:

  1. The first is about requiring spaces around ternary operators tokens, both the ? and the :. Omitting a space in front of the ? was just deprecated in e91c0ff, which was done in view of allowing expressions like T? in the future. The extension in this PR is not required for that, but in my opinion it helps a lot in disambiguating visually at first glance the uses of ternary operators vs the other meanings of ?/: (in particular, ranges).
    For example, this deprecation caught the following line in Base: (size(M, t=='N' ? 1:2), size(M, t=='N' ? 2:1)). To me, it seems unnecessarily difficult to see that 1:2 and 2:1 are not ranges. By the way, in the same spirit it may be desirable to deprecate writing ranges with spaces, e.g. 1 :2. If we had these rules, distinguishing the use of colon in ternary operators, ranges and symbols would be much much easier. The set of parsing rules for ? and : would be purely local, rather than context-dependent, and easy to explain and understand.
    I expect that a major objection to such change is that this should be the job for a linter, not a parser. On the other hand, I really don't see the benefit in allowing a style which to me nearly amounts at code obfuscation, while the "cost" of this change is negligible.
    (There is also an argument of symmetry, since the fact that a space is required before ? but not after simply irks me, but then again it's just me probably.)

  2. The second commit, I would assume, is less controversial, at least in its intent if not in the implementation: it deprecates the use of ? as an identifier. This is possible right now purely by accident (it "slips through" the parser rules), and it has long been recognized as undesirable. See issue ? behaves strangely as an identifier #6286, in particular this comment. See also issue Should ? not be allowed as an identifier name? #19061 for some examples of the silliness which can arise by allowing it. Another major problem IMO in allowing an identifier or expression to start with ? is that it can not be easily entered in the REPL, as it clashes with the help mode. Of course, this deprecation would not disallow the possibility to parse T?, or even use ? as part of an identifier name, provided it is not the first character.
    As far as I'm aware, right now ? is only used in this way by the Nulls.jl package, as a placeholder until the T? syntax is available (Please don't use ? as a unary operator? JuliaData/Missings.jl#17). I guess that they could either live with the deprecation until then, or just use any other symbol among the bazillions that are available, e.g. ❓ (\:question:) or (\APLboxquestion) (cc @ararslan).

@carlobaldassi carlobaldassi added the parser Language parsing and surface syntax label Jul 8, 2017
@ararslan ararslan added the deprecation This change introduces or involves a deprecation label Jul 8, 2017
@ararslan
Copy link
Member

ararslan commented Jul 8, 2017

💯 to this!! I don't have the Scheme chops to review the actual implementation of the changes but I fully approve of the the approach you describe. It seems fine to me for a language's parser (as opposed to a linter) to enforce readable code in cases such as this, when it disambiguates meaning. It also seems like it will make the introduction of T? that much simpler. Thanks for taking this on!

Regarding further deprecations, I would also love to see spaces around the colon in range expressions deprecated. That would complement the changes here quite well, in my opinion.

Copy link
Member

@Sacha0 Sacha0 left a comment

Choose a reason for hiding this comment

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

The non-parser changes lgtm! :)

@ararslan
Copy link
Member

ararslan commented Jul 8, 2017

Note: the current CI failures are unrelated. 32-bit Linux timed out and Windows failed due to existing libgit2 issues.

@tkelman
Copy link
Contributor

tkelman commented Jul 8, 2017

Spaces around the colon in ranges are useful when start, end, or step are calculated from some nontrivial expression rather than a literal or short variable name.

@vtjnash
Copy link
Member

vtjnash commented Jul 8, 2017

@tkelman I've found that parentheses are generally equally adequate (x - 1):2:(end / 2), but I'm also not certain the parser should try to enforce good style, over PR review and a juliafmt (jlformat?) command. Anyways, don't let me derail this PR :)

* deprecate no space after the ? (no space before was already
  deprecated)

* deprecate no space around the :

* fix instances where no spaces were used in Base
@tkelman
Copy link
Contributor

tkelman commented Jul 16, 2017

should probably adjust the NEWS bullet from #22619

@carlobaldassi
Copy link
Member Author

Rebased and updated NEWS and docs. (There is also an unrelated small fix in the NEWS that I happened to catch.)

It seems nobody is against this and that it could be merged.

@JeffBezanson do the parser changes look ok?

@carlobaldassi carlobaldassi changed the title [RFC] Sanitize the ternary operator and question mark parsing situation (deprecations only) Sanitize the ternary operator and question mark parsing situation (deprecations only) Jul 16, 2017
(begin0 (ts:last-tok s)
(ts:set-tok! s #f)))))
(if (and (not allow-question-mark) (eq? t '?))
(syntax-deprecation s "`?` used as an identifier" ""))
Copy link
Member

Choose a reason for hiding this comment

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

This should be part of the function check-identifier. See if that works. If it does, we might be able to get rid of allow-question-mark as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah thanks, I don't know how I missed that. It seems to work fine, I have updated the PR.

@carlobaldassi
Copy link
Member Author

Addressed review comments, tests pass.

@JeffBezanson
Copy link
Member

I manually squashed the related commits and merged into master. It won't recognize the PR as merged, so closing. Oh well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecation This change introduces or involves a deprecation parser Language parsing and surface syntax
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants