deprecate typealias in favor of const assignment or A{B} = ...

[JeffBezanson]

typealias is now completely redundant, as it is just a const assignment of a name to a type. I also added the syntax

Vector{T} = Array{T,1}

in analogy to short-form function definitions.

[KristofferC]

When do you have to use const and when can the short form be used? And if you forget the const will it just give you bad performance?

[yuyichao]

Why do these not have const?

[JeffBezanson]

In function definitions f(x) = x, const f is inserted, and the same happens here. a{b} = c is also a const assignment. These are usually global variables, so the same performance issues apply. However these are very often used only in method signatures, where they're evaluated once at the top level, in which case there's no performance impact.

[JeffBezanson]

I just realized X{} = ... (the zero parameter case) works, and since it needs no where expressions, is equivalent to just a const assignment. Not sure if feature or bug.

[stevengj]

I'm all for getting rid of typealias.

However, I'm skeptical that we want a new abbreviated syntax here. Parameterized typealiases are a lot less common than one-line functions, and every new syntax we add also makes the language more complicated to learn. const Vector = Array{T,1} where T isn't too bad. On the other hand, Vector{T} = Array{T,1} is more readable, and looks more like how you use the Vector type.

Can we just do const Vector{T} = Array{T,1}? Even though the const is somewhat redundant, it at least makes it look more like other constants. The implicit const seems a bit confusing.

[JeffBezanson]

I'm fine with allowing const Vector{T} = Array{T,1}. But without const, it will still be constant :)

[JeffBezanson]

Ah, fortunately due to sufficiently generic code const A{B} = C already works, as does const f(x) = x. I think I will disallow A{} = B though since it's not meaningful.

[yurivish]

What are the practical differences between saying Vector = Array{T,1} where T (without const) and const Vector = Array{T,1} where T?

[StefanKarpinski]

If Vector is non-const then anything that references it will have bad performance. Similar to using non-const globals in general.

[JeffBezanson]

Yes, it's just a normal const vs. non-const binding.

[yurivish]

Thanks. I like the idea of a convenient syntax for the parametric case but am a little worried that the performance subtleties will trip people up if the const is implicit.

I'm pretty familiar with Julia, but the parallels between the new syntax (A{T} = B{T, 1}) and normal variable declaration (A = B) feel like they'd pull me strongly towards accidentally leaving a const off of a typealias of the latter form.

Julia itself has quite a few typealiases without parameters, so it seems to be a pretty common thing.

[tkelman]

looks like this test

julia/test/parse.jl

Line 701 in 6d6a3c3

@test expand(:(i==3 && i+=1)) == Expr(:error, "invalid assignment location \"==(i,3)&&i\"")

now needs extra spaces around the && ? seems kinda unrelated but harmless enough?

edit: should probably run and update any doctests that will have their output changed here

[JeffBezanson]

am a little worried that the performance subtleties will trip people up if the const is implicit.

Agreed; it would really be nice if global bindings could be const by default (and use e.g. Ref for mutating). That would be a good solution everywhere but the REPL it seems.

[StefanKarpinski]

it would really be nice if global bindings could be const by default ... That would be a good solution everywhere but the REPL it seems.

What about everything being const once the module is closed? "How would this help a script in a file?" you ask – since the whole script runs before the Main module is closed. However, if Main has a main() function we could automatically called when the script ends – after the Main module is closed, so the constness of bindings would actually be reliable at that point.

[JeffBezanson]

That could work. Of course if any code gets compiled before the module closes, it would not be able to take advantage of const-ness. Maybe it could be a per-module property; you can say that a certain module should have non-const-by-default bindings, which would normally only be used by the repl.

[StefanKarpinski]

We could keep track of methods that were compiled before the module was closed and which depended on a global. Closing the module would then invalidate their code, forcing them to be recompiled. Confused face was because I don't like the idea of this as a module setting.

[JeffBezanson]

Yes we could do that, but compiling things twice is going to hurt load times even more.

[JeffBezanson]

Ok, I took out the change to deparse that broke a test since it doesn't belong here. The extra spaces do look better, but that can be done separately.

[StefanKarpinski]

If a function uses a global while its module is still open, that would be a good heuristic to decide to use an interpreter – if we end up having a full-fledged one. That way compilation would occur:

1. On first usage if the function only uses const globals;
2. On first usage after the module is closed otherwise.

That way the compilation time wouldn't be affected.

[iamed2]

The behaviour with const A{B} = C is kind of confusing for me:

julia> const Foo{Int} = Vector
Array{T,1} where T

julia> Foo
Array{T,1} where T

julia> Foo{Int}
Array{Int64,1}

julia> const Bar{Int} = Float64
Float64

julia> Bar
Float64

julia> Bar{Int}
ERROR: TypeError: Type{...} expression: expected UnionAll, got Type{Float64}

julia> const Baz{1} = Int
ERROR: syntax: malformed expression

Maybe these could use better errors?

[JeffBezanson]

I'll fix the malformed expression one.

The B in A{B} = C is a formal argument name, like f(Int) = Int. I know what you mean, but calling an argument Int does obscure things a bit.

[iamed2]

Ah thanks, the first example makes sense now.

For the second, is the extra argument being ignored in the definition but not in usage? I would expect that if Bar{Int} is going to error then const Bar{T} = Float64 should error.