For reference, a staged function is something sorta similar to a macro, except it lets you take advantage of Julia's inferred type info. Contrived (and wholly redundant) example:

  stagedfunction foo(x)
      if x == Int
          :(2x)
      else
          :x
      end
  end

  y = 1
  foo(y)  == 2
  y = 1.
  foo(y) == 1.0 

Again, just like a macro, except that before `x` is quoted you work with the type of y instead of the symbol `y`. This means you can do even more crazy code specialisation, including on e.g. matrix dimensions or generating appropriate FFI calls based on arbitrary input types. It has zero overhead and you can use it just like a regular function.

Very cool, and I think people will do really interesting things with this (especially after mixing them with macros).

This sounds very similar to an approach called Lightweight Modular Staging (pioneered in Scala by the Oderski group - http://scala-lms.github.io/ and also in Lua - http://terralang.org/). While this is great for specializing numeric code based on runtime invariants like dimensionality, I think people are finally looking at using the idea in other domains - for example, runtime generation of DSL code on a per instantiation basis. Imagine taking a high level SQL query, building the operator tree in a Julia DSL and optimizing that, and then JITing the entire thing taking into account low level storage details and the particular sets of operators and joins (http://msr-waypoint.com/en-us/events/dcp2014/rompf.pdf). This is very exciting to see in another typed language!

You mean like blaze in python?: http://blaze.pydata.org/docs/v_0_6_5/index.html

Blaze has a bit of a broader focus than what I was talking about, since blaze mostly offloads the actual computation to a particular backend. But a combination of blaze and a custom lowering of the computation into machine code using numba would be similar (although without the type safety for guaranteeing that certain optimizations are possible)

I believe that the numba compilation is planned for the coming year.

wbhart This sounds like a really interesting project! Is it already on Gitub? I suspect there are others in the Julia community who would love to join the effort too when you have something ready.

It is, essentially. https://github.com/wbhart/Nemo.jl

See the wiki for a few bits of our planning that have actually made it online. Our current focus is twofold: 1) interface to Singular (http://www.singular.uni-kl.de/) from Julia 2) write a Singular interpreter in Julia (as an independent implementation of the Singular language). (Of course Julia will always be the main language of Nemo. The Singular interpreter will simply be a way for current users of Singular to benefit from Julia/Nemo and for users of Nemo to leverage the vast quantity of Singular library code out there written in the Singular language. And to have that code run faster of course.)

Yesterday we called the Singular C++ library, initialised it and created a Singular ring from within Julia for the first time. So very early days in that direction.

What is already committed on GitHub is a Julia interface to the flint library (which is pure C). Nemo is still a prototype, but you can Pkg.clone/Pkg.build it (Windows 32/64 support is there but clunky).

I will be visiting the Pari/GP people in January and working on a Nemo interface to Pari then.

What are the advantages of using Singular for the project vs. Axiom or Maxima?

Singular is only a component of the project. Maxima and Axiom contain almost none of the mathematical knowledge contained in the Singular project. No one wants to write hundreds of thousands of lines of code in some other system.