BUG: currently indexing an array thinks the array is a type about atom-language-julia HOT 10 CLOSED

Hmmm... without getting into naming conventions, I don't see a good way around -- I added this type identification, but I'm for just removing it for now.

from atom-language-julia.

Since typed array calls (empty or not) are actually just getindex calls anyway there's no way to separate the two cases. Arguably, since Functions, Types and Modules are really just types of run-time value, trying to guess their presence from syntax is a non-starter – like trying to guess whether x is an Int from syntax alone.

I don't think it would be so bad to just highlight identifiers beginning with a capital letter as types. Yes, that technically means people can highlight their integer as a type by defining Foo = 1, but IMO the (very minimal) consequences of doing that are on them.

from atom-language-julia.

But what about differentiating between MyType and MY_INDEXABLE_CONST? It's impossible to assign acronyms or single-letter names to one bin or the other with certainty.

from atom-language-julia.

Types and consts could just have the same non-default colouring. After all they are both a type of constant :)

It's basically consistent that identifiers with capitals mean "slightly unusual / notable kind of variable". Really we'd be overloading the type.julia scope to refer to that, and actual Julia types are a subset. Conceptually, it is at least consistent.

I'm not adamant about it or anything, but for the reasons above I think the only alternative is to avoid differentiating between normal vars and types altogether. Having some differentiation seems better than none at all, even if "notable kind of variable" is a relatively broad category (including types, modules, consts etc).

from atom-language-julia.

I think differentiating using a regexp on the convention that types are PascalCase and variables_use_underscores_and_lowercase would work in 99% of my Julia code.

from atom-language-julia.

The array indexing highlighted as Type really confused me in my code. Is there any plan to fix this bug? or any workaround at the moment?

from atom-language-julia.

Also in the following code

convert(Array{T}, r)

shouldn't Array{T} be treated as Type?

from atom-language-julia.

I'll put in a vote for not applying coloring unless it is actually correct.

from atom-language-julia.

Yeah, we just should not color types since it's impossible to tell what they are from syntax alone (and maybe optionally color words in camel case as types).

from atom-language-julia.

I agree with what is said here. If anyone has the time to implement this I will happily review a PR, I don't think I'll be able to do it myself.

from atom-language-julia.