Breaking into many lines and renaming variables would go a long way to make this code look more like C.
http://www.jsoftware.com/jwiki/Essays/Incunabulum
It segfaults, because it's written in rather non-portable C that assumes sizeof(function pointer) == sizeof(int), among other things. It's an interesting piece of code, though.
I don't completely understand it - I'm confused by the concept of rank in J, and haven't worked with the language enough to get over that hump. (IIRC, K avoids "rank" entirely, and just uses either an array or an array-of-arrays for multiple dimensions.) I've only been a tourist in the APL family of languages, but what I've seen has left me quite impressed.
Rank shouldn't be something to get confused about; if it is you're probably overthinking it.
What did you find confusing about it?
Thanks for the offer, but I didn't get that far because I decided I was better off focusing on Erlang for the time being. I'm very curious about that language family, I'm just trying to not spread myself too thin. When I get back to it, I'll try working through the J labs - it's probably a much better way to pick it up than untangling a semi-obfuscated interpreter.
I think it'd be easier to untangle if you already had a working knowledge of the language but given the line-noisy look of J I can't blame you for trying the shortcut.
The interactive J labs are very good. You might also find the J for C programmers discussion of rank particularly helpful if you are looking at learning by understanding an implementation.
I figure the array languages will make a minor comeback soon what with gpus / larrabee / etc showing up on the horizon and what with more-versatile input devices showing up (making it easier to go back to funky symbols instead of line noise).
What specifically do you see as the fit between GPUs and array languages?
This isn't really a new idea: http://portal.acm.org/citation.cfm?id=579.357248&coll=GU...
...(and gpus / larrabee etc. aren't solely vector processors, but the idea is apparent).
Most of the bulk numeric actions in an array language map pretty nicely to the data-parallel approach you need to use to take advantage of a gpu or larrabee (if it ever shows up); in particular take a look through this:
http://www.ncsa.illinois.edu/~gshi/LRBni_cheatsheet.pdf
...and see how much more straightforward it'd be to take advantage of (compared to SSE and so on). Your interpreter has to be a little more sophisticated (work has to be kept in units of 512 bytes) but seems much more tractable than previously.
Since this isn't a new idea there's history to learn from; it was previously the case that you'd get a speedup from offloading work to the vector units but not really a cost-proportionate one. But now if you look at the performance differential between cpus and gpus and their relative costs it starts making sense again.