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

New syntax deprecation warnings double print output in REPL #8603

Closed
jakebolewski opened this issue Oct 7, 2014 · 10 comments
Closed

New syntax deprecation warnings double print output in REPL #8603

jakebolewski opened this issue Oct 7, 2014 · 10 comments
Labels
status:won't change Indicates that work won't continue on an issue or pull request

Comments

@jakebolewski
Copy link
Member

Julia/julia-dev-33 [master] » ./julia
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+980 (2014-10-06 19:52 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 1224d7f (0 days old master)
|__/                   |  x86_64-apple-darwin13.4.0

julia> (Symbol=>Int)[:a => 1]
WARNING: deprecated syntax "(Symbol=>Int)[a=>b, ...]".
Use "Dict{Symbol,Int}(a=>b, ...)" instead.
julia> (Symbol=>Int)[:a => 1]

WARNING: deprecated syntax "(Symbol=>Int)[a=>b, ...]".
Use "Dict{Symbol,Int}(a=>b, ...)" instead.
Dict{Symbol,Int64} with 1 entry:
  :a => 1

julia>^d

Julia/julia-dev-33 [master] » ./julia -e "(Symbol=>Int)[:a=>1]"

WARNING: deprecated syntax "(Symbol=>Int)[a=>b, ...]".
Use "Dict{Symbol,Int}(a=>b, ...)" instead.
@jakebolewski jakebolewski changed the title New syntax deprecation warnings double print their output from the REPL New syntax deprecation warnings double print output in REPL Oct 7, 2014
@JeffBezanson
Copy link
Sponsor Member

This must be because the REPL somehow ends up parsing the input twice. The deprecation warnings make parsing non-pure. I noticed this, but figured it wasn't so important. You only really need the warnings for files, to see which lines to change.

@Keno
Copy link
Member

Keno commented Oct 7, 2014

This also means that if you have the old syntax inside a multiline expression in the REPL the warning will show. Can we have a mode to the parser that does not print them?

@JeffBezanson
Copy link
Sponsor Member

Just consider yourself really, really warned. There's no need to use the old syntax in the REPL. The old syntax only needs to be supported at all for the sake of loading packages and source files that haven't been updated yet. If anything, it would make sense for the warnings to be syntax errors in the REPL rather than silencing them.

@mbauman
Copy link
Sponsor Member

mbauman commented Oct 7, 2014

This isn't unique to these new syntax deprecations. It also has been happening for a long time with older syntax deprecations (such as indexing with missing halves of a range). It's simply because the REPL needs to parse the input to determine if the line is complete or not before actually executing it.

julia> zeros(1)[1:]
WARNING: deprecated syntax "x[i:]".
Use "x[i:end]" instead.
julia> zeros(1)[1:]

WARNING: deprecated syntax "x[i:]".
Use "x[i:end]" instead.
1-element Array{Float64,1}:
 0.0

@JeffBezanson
Copy link
Sponsor Member

Speaking of which, I believe that syntax can be fully removed for 0.4.

@ivarne
Copy link
Sponsor Member

ivarne commented Oct 7, 2014

"x[i:]" is an error after #8607

@Keno
Copy link
Member

Keno commented Oct 7, 2014

Not quite the right behavior though, because it raises an error rather than returning an error as other syntax errors do.

@Keno
Copy link
Member

Keno commented Oct 7, 2014

Actually, nevermind I guess syntax errors always abort the REPL multiline input? Not sure I like that behavior.

@StefanKarpinski
Copy link
Sponsor Member

They do, which is kind of unfortunate. I would be happier if that were not the case but it's a tricky design.

@jakebolewski
Copy link
Member Author

I agree that this behavior kind of sucks, but I don't know if it is worth fixing it at the moment.

@JeffBezanson JeffBezanson added the status:won't change Indicates that work won't continue on an issue or pull request label Oct 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:won't change Indicates that work won't continue on an issue or pull request
Projects
None yet
Development

No branches or pull requests

6 participants