I intend to work on julia as a GSOC project this year. These are the ideas that I have in mind:
- Bringing FunctionalCollections to a usable state. I’m familiar with the clojure’s implementations of persistent collections and it looks like FunctionalCollections are inspired by them. These are some of the improvements that could be made to them:
a) Introduce transient versions of these libraries
mapoperation, we could create a clone of the input collection with similar trie structure and undefined values, and then iterate over it while filling in the mapped values.
c) Experiment with different values of shift width based on the size of element type, to account for cache line size. See if that affects performance in any way.
d) Go through the implementation of some of the tools mentioned here, see if there’s anything useful which could be ported over to julia.
The ideas page mentions that functional collections could be used “to accelerate computational problems in the compiler”. Isn’t it the case that functional collections trade speed for guarantees like simpler multi-threading? How can they be used in julia to speed up computational problems?
- Create a package management tool similar to
cargofor julia environment, preferably in julia itself. The community bonding period will be spent understanding how package management works in julia, and reading the source of
Pkg.jl. The end result will be something similar to
cargo, which would allow users to easily setup a template project with minimal work, with support for tests, benchmarks and preferably custom targets.
Pkgrepl already provides most of the stuff mentioned here, but it’s hidden in the julia repl. Having a binary specifically for project management will be very nice to have.