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

-- parses as an operator but ++ doesn't #9532

Closed
jaakkor2 opened this issue Jan 1, 2015 · 9 comments
Closed

-- parses as an operator but ++ doesn't #9532

jaakkor2 opened this issue Jan 1, 2015 · 9 comments
Labels
needs decision A decision on this change is needed parser Language parsing and surface syntax

Comments

@jaakkor2
Copy link
Contributor

jaakkor2 commented Jan 1, 2015

I would like to be able to write 1--2 to get 3. Additional spaces or parenthesis are not convenient.

Matlab and Python allow this. JavaScript not, because there ++ and -- are increment/decrement operators, but -+ and +- are ok.

julia> 1++2
3

julia> 1-+2
-1

julia> 1+-2
-1

julia> 1--2
ERROR: -- not defined

julia> 1- -2
3

julia> 1-(-2)
3
@vtjnash vtjnash added the bug Indicates an unexpected problem or unintended behavior label Jan 1, 2015
@tkelman
Copy link
Contributor

tkelman commented Jan 2, 2015

I hope you're not expecting anyone else to read code that has 1--2 in it, I'd almost call that an enforced-readability feature if not for 1++2 currently working.

@ivarne
Copy link
Member

ivarne commented Jan 2, 2015

I would be surprised to find 1--2 == 3. Adding space makes it much more readable.

@mschauer
Copy link
Contributor

mschauer commented Jan 2, 2015

Why is this a bug? -- is a free operator symbol that can be defined by the user, for example even by -- = + if that is really wanted.

@ihnorton
Copy link
Member

ihnorton commented Jan 2, 2015

@mschauer agreed, but it does seem inconsistent that ++ is not parsed as a unique operator:

julia> parse("1++2")
:(1 + 2)

@JeffBezanson JeffBezanson changed the title ERROR: -- not defined -- parses as an operator but ++ doesn't Jan 2, 2015
@JeffBezanson
Copy link
Member

Here's what we'll do:

  1. Decide whether we want -- and ++ as operators.
  2. For now keep a++b parsing as a + (+b) to avoid spurious breakage.
  3. Make -- a syntax error while we decide on (1). Note ** is already a syntax error to avoid confusion with ^.

@JeffBezanson JeffBezanson added needs decision A decision on this change is needed and removed bug Indicates an unexpected problem or unintended behavior labels Jan 2, 2015
jakebolewski added a commit that referenced this issue Jan 2, 2015
jakebolewski added a commit that referenced this issue Jan 2, 2015
@jakebolewski
Copy link
Member

-1 on having -- and ++ be valid operators.

@StefanKarpinski
Copy link
Member

I once proposed that ++x and --x could default to x += one(x) and x -= one(x), but allow more efficient implementations (e.g. for BigInts), the main advantage being that it avoids the type instability that can be introduced by x += 1, e.g. for UInt32 on a 64-bit system. I'm not sure how important that is, however, since it doesn't seem to come up that often.

@JeffBezanson
Copy link
Member

It would be nice to have pred and succ functions. It would be a bit odd to have syntax for those functions in combination with assignment, but not the functions themselves.

I ran into this yesterday, where in the UnitRange constructor pred(start) would be better than start-one(stop-start)).

@jakebolewski jakebolewski added the parser Language parsing and surface syntax label Jun 2, 2015
@jakebolewski
Copy link
Member

I don't think there is anything left to do here. Deciding on -- and ++ as operators seems like a separate issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs decision A decision on this change is needed parser Language parsing and surface syntax
Projects
None yet
Development

No branches or pull requests

9 participants