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

remove a[5:] syntax #4678

Closed
magistere opened this issue Oct 29, 2013 · 18 comments
Closed

remove a[5:] syntax #4678

magistere opened this issue Oct 29, 2013 · 18 comments
Assignees
Labels
kind:breaking This change will break code needs decision A decision on this change is needed
Milestone

Comments

@magistere
Copy link
Contributor

Julia:

julia> a=[1:10]
10-element Array{Int32,1}:
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10

julia> a[5:]
6-element Array{Int32,1}:
  5
  6
  7
  8
  9
 10

julia> a[:5]
5

Python:

>>> a=range(1,11)
>>> a
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> a[5:]
[6, 7, 8, 9, 10]
>>> a[:5]
[1, 2, 3, 4, 5]
>>>
@lindahua
Copy link
Contributor

The problem is that :5 is parsed as 5, so a[:5] is equivalent to a[5].

@pao
Copy link
Member

pao commented Oct 29, 2013

What is a[5:] getting parsed as? The correct syntax for getting the rest of the array is a[5:end].

@magistere
Copy link
Contributor Author

I think that a[5:] is parsed as a[5:end] now. Maybe it will be better to forbid this?

@ivarne
Copy link
Sponsor Member

ivarne commented Oct 29, 2013

julia> dump(:(a[:9]))
Expr 
  head: Symbol ref
  args: Array(Any,(2,))
    1: Symbol a
    2: QuoteNode 
      value: Int64 9
  typ: Any

julia> dump(:(a[3:]))
Expr 
  head: Symbol ref
  args: Array(Any,(2,))
    1: Symbol a
    2: Expr 
      head: Symbol :
      args: Array(Any,(2,))
        1: Int64 3
        2: Symbol :
      typ: Any
  typ: Any

@StefanKarpinski
Copy link
Sponsor Member

I think that a[5:] is parsed as a[5:end] now. Maybe it will be better to forbid this?

I kind of agree with disallowing this. We would deprecate it first for a while and then remove the syntax altogether.

@ghost ghost assigned JeffBezanson Nov 25, 2013
@JeffBezanson
Copy link
Sponsor Member

I'd be ok with removing this, but it seems to be pretty popular (grepping through packages). Taking the "tail" of a vector or string is common, and being able to do it with 3 fewer characters is seductive.

@kmsquire
Copy link
Member

As in the original issue, a[:5] is also seductive (I've certainly written this), but I assume there's little chance of it being parsed as a[1:5]...

@JeffBezanson
Copy link
Sponsor Member

Well, that's a fair point... get ready to see the deprecation warning for this every day for the next year :)

@johnmyleswhite
Copy link
Member

I would love to see this get deprecated.

@StefanKarpinski
Copy link
Sponsor Member

We could disallow :\d+ as a syntax for a literal number since that's a pretty useless thing to do and print a warning that says "you probably want 1:n" instead.

@RauliRuohonen
Copy link

If you're disallowing :\d+, then you could just make it work as 1:n for a[:n], and error outside indexing context, like n: currently is. E.g.

julia> 5:
ERROR: syntax: invalid ":" outside indexing

@kmsquire
Copy link
Member

One problem with allowing a[:3] is that users might then think they can do

d=3
a[:d]=4

and wonder why they would get an error.

@StefanKarpinski
Copy link
Sponsor Member

As a general principle, we don't allow the context in which an expression occurs to affect its meaning. Making :3 mean :3 in indexing context and be an error in other contexts would violate that. @kmsquire's example is precisely what that sort of thing is a bad idea. When you write d = 3; a[:d] = 4 at least you get a no method error for indexing with a symbol instead of it silently doing the wrong thing, which is why the current behavior of a[:5] is so bad. We could add methods for indexing arrays with symbols that raises a more helpful error.

@JeffBezanson
Copy link
Sponsor Member

We could, but I prefer to let the set of available definitions correspond to what is actually possible, and not define everything just for convenience. For example applicable(getindex, array, :d) will happily report true in that case. Better to handle this in the code that prints method errors.

@StefanKarpinski
Copy link
Sponsor Member

Sure, that did feel a bit "off" to me too.

@StefanKarpinski
Copy link
Sponsor Member

So the basic plan is to just make :\d+ illegal syntax.

@RauliRuohonen
Copy link

Very good point about a[:d]. Then a[d:] working but a[:d] not is confusing indeed. You could make a[:d] work as expected, forcing the use of a[symbol("d")] in indexing context for the unlikely use of symbols, but that's sort of context-dependent.

Amusingly, there is a context dependency in the "wrong" direction:

julia> :end
ERROR: syntax: extra token "end" after end of expression
julia> a[:end]
ERROR: no method getindex(Array{Int64,1}, Symbol)

So in the case where ":end" might reasonably be a symbol it is a parse error, and in the case where it may not reasonably be symbol it is parsed as one :)

EDIT: Ah, I was thinking of arrays only. For dictionaries, the use of symbol indexes is not unlikely at all, and at parsing time you won't know the difference. So illegalization seems like the only reasonable option. Still, the case with :end is a curious one. Even (:end) won't work, but a[:end] does.

@StefanKarpinski
Copy link
Sponsor Member

Yeah, end is a bit different. We don't allow end as a symbol – it's a keyword and keywords cannot be used as symbols (that's basically what keyword means). As a keyword, end is inherently syntactic and syntactic elements are always context-dependent – you can't just use if anywhere you like. The two places you can use end are to close a block or to mean endof(<the array I'm currently indexing into>) when you're indexing into an array. Using end by itself is incomplete syntax, just like writing else println("foo") end by itself isn't valid syntax.

dancasimiro added a commit to dancasimiro/WAV.jl that referenced this issue Jan 24, 2014
This syntax was deprecated as a result of the discussion in
JuliaLang/julia#4678.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:breaking This change will break code needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

9 participants