Roadmap
This page serves to keep track of some of the major items to be tackled for upcoming Pure releases.
Pure 1.0 is basically finished at this point, except for the update to the new MCJIT. Pure still uses the old LLVM JIT right now, which is only available for LLVM versions up to 3.5. This is an important issue which has been on our TODO list for some time, but the update is not straightforward, as the MCJIT is not a drop-in replacement for the old JIT. In particular, it doesn't have the capability to dynamically swap out code at the function level. Basically, each global Pure function will need to be in its own LLVM module, which requires a major rewrite of Pure's code generation backend.
LLVM 3.5 is still available for all major operating systems, so Pure can still be used with the old JIT for the time being. Nevertheless the MCJIT offers some considerable advantages in that it's supposedly faster than the old JIT and supports more architectures because it uses the existing codegen infrastructure. In particular, it should make it possible to make Pure work on interesting non-x86 architectures such as ARM (the old JIT never really worked there). So this will hopefully be tackled real soon now.
Here's some stuff to tackle once Pure 1.0 is out.
Dubiousjim proposed some changes to the standard library which are discussed on their own page. While the proposal is a bit dated now, there is some stuff in there which should be worth looking at.
Another open issue we've been discussing on the mailing list is whether we might want to support native 64 bit machine integers on 64 bit platforms. At present, Pure uses 32 bit machine integers everywhere, which provides for better cross-platform compatibility.
We plan to provide some high-level concurrency features, but it's not clear yet what abstraction best fits Pure. Approaches that we've been considering are parallel maps and concurrent futures. Especially the latter seems a good fit since Pure already has lazy futures.
Dubiousjim proposed the idea to add delimited continuations as an abstraction for coroutines. That won't give us real parallelism, but is somewhat easier to implement (e.g., like this) and would still be useful for some applications in FRP like realtime processing of event streams (e.g., inside Pure's Pd external).
Gregory Burd has suggested an approach called CALM ("consistency as logical monotonicity") which was developed at UC Berkeley and has been implemented in the Bloom programming language. We still have to look into that.
The Pure compiler could generate better code, e.g., by using unboxing optimizations for numeric types and inlining of saturated global function calls. There are some other opportunities for optimizations in the marshalling of GMP mpz_t and int** et al vector values, in order to avoid malloced temporaries as much as possible.
Another feature that would be nice to have is separate compilation at the module level. However, this isn't easy to implement given how Pure allows rule for the same function to be scattered out over different modules.