gistfile1.txt

If I were to work on NimBorg, these would be the things I'd be busy with:

* Try to do something useful with the lua bindings. Doing that is certain to expose plenty of missing functionality. Pick up any lua library and start porting its example snippets to nimrod, and you'll find out what is missing. The same goes for python, but the lua bindings are more rudimentary.

* callbacks to nimrod from lua/python. This is a bit risky if done naively, because it can create problems for the GC. I don't know lua well enough to say how that'd work, but in python you'd have to construct a PyTypeObject and populate its tp_call field. The wrapper would probably convert the first argument of tp_call to a pointer to the nimrod object being wrapped, and the two other arguments (args and kw) to PPyRef. This is the easy part. 
The hard part is getting GC to work with this. You can allocate your callable nimrod object on the python heap, I suppose, and access it through something that has the same memory-management semantics as PPyRef. The problem in that case would be that your callable object wouldn't be allowed to hold any managed ref to nimrod objects that are not also on the python heap. 

As long as Nimrod's GC and the foreign language GC are unaware of each other, the user has to be aware of the boundaries between them. This means that the user has to do some amount of manual memory management, or avoid anything that leads to cycles that cross the heap boundary between nimrod and python/lua. 

Since Nimrod is an ambitious language, perhaps its developers would be interested in the difficult task of cross-language GC. This is a bit harder than anything I've done with NimBorg so far, but it could interest someone who likes greater challenges. The idea is this: 
* allow Nimrod objects to reference foreign objects
* create proxy objects in the foreign heaps that contain pointers to nimrod objects. 
* keep the pointed-to nimrod objects from being deallocated using GC_ref
* occasionally run mark-and-sweep across all language heaps combined

I'm not aware of any language that accomplishes this feat - collecting cycles across FFI boundaries. This could be a killer feature indeed - seamless FFI with the peace of mind that comes with GC. 

* Efficient numpy array access - you can treat numpy arrays just like any other python object and access it through the python API, but it's much faster to bypass python and access the memory directly. I wrote float64Buffer and float32Buffer for that, but those are pretty rudimentary. They lack multidimensional array indexing. Another improvement would be to support a fast and generic interface, which could be named e.g. PyDenseArray[T].

* if someone should take the trouble to add java to nimborg, that would be pretty awesome too.