By: This week in julia

Re-posted from: http://thisweekinjulia.github.io/julia/2014/10/25/October-25.html

The maintenence release Julia 0.3.2 was posted on Wednesday. A total of 70 commits were meticulously backported from the master development branch, bringing lots of bugfixes, documentation updates, and even a few performance improvements to the 0.3 release.

Major breaking changes on 0.4

The function call operator is now overloadable (#8712)! This has lots of wide-ranging implications… some of which I’m sure haven’t even been realized yet. Here’s what it already means:

• It makes type constructors first class methods of the call function. You can still create constructor methods with the old function-like T(x,y,z) = ...; syntax, or you can add methods to call directly (e.g., call(::Type{A},x,y,z) = ...;). While I’m not familiar with the internals, it apparently simplifies a lot of the code surrounding type constructor generation. This “big new feature” resulted in a net decrease of 10 lines of code. Impressive!
• There’s now a fallback method (by default) for all types such that calling T(args...) means convert(T, args...)::T (39dfd92). This means that you can now call Int(2.0) with the leading capital!
• This is paving the way towards possibly deprecating the lowercase int functions (#1470: int, Int and box). One question is what to do with its elementwise methods (e.g., int([1.0,2.0,3.0]) to convert an Array{Float64} to an Array{Int}), but with one small optimization (2cb98a0), map(Int,[1.0,2.0,3.0]) is now just as fast as the old lowercase method. This is an interesting case; typically map is slower than explicit for loops since it cannot specialize on the function value, but when called with a type it can emit specialized code for that constructor.
• This same trick is exploited in lots of the map/reduce code, using dummy Functor types to represent specific functions to allow method specialization and inlining. But with call overloading, those ‘dummy’ Functor types just got a lot smarter. Instead of using a secondary helper function to actually evaluate each function, you can overload the call operator for each Functor directly so the type behaves just like its desired function. It makes the Base reduction code a little bit simpler and much nicer to read. (#8790)
• It also obviates the need for some functions like inf and nan, which are now deprecated. Previously, you would call inf(T) to get the representation of infinity in type T. With this change, however, you can simply type the reverse: T(Inf). (#8776)

I’m sure lots of this is still in flux, but this turned out to be a bigger and more exciting change than I expected. It has also broken lots of packages (although that may just be the result of a few dependencies breaking and cascading through the ecosystem), so in the short term beware.

Other 0.4 project updates

• Work to allow static compilation and caching of modules (to reduce package load time dramatically) continues. A big backend change was merged (static compile part 3, #8656) in preparation for work on the user interace (as proposed part 4, #8745). There are still some questions about the underlying behaviors, but it’s exciting to see precompilation moving forward.
• The documentation system also keeps marching along, now in a new PR (#8791).

Package ecosystem

• A few weeks ago, Tim Holy proposed an alternative to multiple inheritance that has since become known as the “Tim Holy Traits Trick” (THTT) (comment on #2345). In short, it uses functions to dispatch on traits instead of using an inheritance tree to dispatch on ancestors. At its core, though, it allows for multiple interfaces. Mauro Werder took this idea and ran, putting together the Traits.jl package which uses macros to formalize interface definition, implementation, and dispatch. It’s not officially registered, but I think it’s all rather clever and worth a mention.