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

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

Merged
merged 1 commit into from
Feb 12, 2017

Conversation

JeffBezanson
Copy link
Member

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.

@JeffBezanson JeffBezanson added this to the 0.6.0 milestone Feb 7, 2017
@ararslan ararslan added deprecation This change introduces or involves a deprecation design Design of APIs or of the language itself types and dispatch Types, subtyping and method dispatch labels Feb 7, 2017
@KristofferC
Copy link
Member

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?

base/array.jl Outdated
typealias DenseVector{T} DenseArray{T,1}
typealias DenseMatrix{T} DenseArray{T,2}
typealias DenseVecOrMat{T} Union{DenseVector{T}, DenseMatrix{T}}
AbstractVector{T} = AbstractArray{T,1}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do these not have const?

@JeffBezanson
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

stevengj commented Feb 7, 2017

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
Copy link
Member Author

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

@JeffBezanson
Copy link
Member Author

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.

@JeffBezanson JeffBezanson force-pushed the jb/typealias branch 2 times, most recently from abf6f9b to 6d6a3c3 Compare February 8, 2017 22:17
@yurivish
Copy link
Contributor

yurivish commented Feb 8, 2017

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

@StefanKarpinski
Copy link
Member

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

@JeffBezanson
Copy link
Member Author

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

@yurivish
Copy link
Contributor

yurivish commented Feb 9, 2017

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
Copy link
Contributor

tkelman commented Feb 9, 2017

looks like this test

@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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

StefanKarpinski commented Feb 9, 2017

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
Copy link
Member Author

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

@JeffBezanson
Copy link
Member Author

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
Copy link
Member

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.

@yuyichao yuyichao deleted the jb/typealias branch February 12, 2017 19:25
@iamed2
Copy link
Contributor

iamed2 commented Feb 12, 2017

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
Copy link
Member Author

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
Copy link
Contributor

iamed2 commented Feb 12, 2017

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.

martinholters added a commit to HSU-ANT/ACME.jl that referenced this pull request Feb 13, 2017
maleadt added a commit to maleadt/LLVM.jl that referenced this pull request Feb 13, 2017
maleadt added a commit to JuliaGPU/CUDAdrv.jl that referenced this pull request Feb 13, 2017
maleadt added a commit to JuliaAttic/CUDArt.jl that referenced this pull request Feb 16, 2017
vchuravy pushed a commit to JuliaAttic/CUDArt.jl that referenced this pull request Feb 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecation This change introduces or involves a deprecation design Design of APIs or of the language itself types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants