uemacs VS Co-dfns

Neat, I am a fan of minimalist text editors. There is also uEmacs: https://github.com/torvalds/uemacs

maybe you're talking about the uEmacs Linus Torvalds still uses today? it's still maintained by him to fit his needs: https://github.com/torvalds/uemacs

u/DellOptiplexFan Ironic, since the literal creator of Linux uses a fork of microemacs https://github.com/torvalds/uemacs

Torvalds's Emacs is nice. https://github.com/torvalds/uemacs

Looks like he uses a thing called uEmacs.

Why don't you ask Linus? Or even better, read his motivation in his fork of microemacs (not GNU Emacs).

He doesn't. Linus uses MicroEMACS [0], which is an entirely different editor that uses emacs bindings.

It's not the lisp machine that incidentally happens to edit code that GNU Emacs is.

Or, as he puts it [1]:

> I use this abomination called "micro-emacs", which has absolutely nothing to do with GNU emacs except that some of the key bindings are similar.

[0]: https://github.com/torvalds/uemacs

Then on the other hand he has his own fork of µEmacs: https://github.com/torvalds/uemacs

Huh. This is the commit that introduces the register model: https://github.com/Co-dfns/Co-dfns/commit/f89919144f22441f21...

In the compiler, it's working with dense adjacency matrix representations, so this will be at best O(n^2) in whatever the relevant sort of node is (expressions? functions?). "at present is not optimized" seems a bit of an understatement here: I've never heard of these sorts of graph algorithms being possible with good asymptotics in an array style. In practice, I think any value of Co-dfns would be more in the fact that it emits GPU code than that it does it quickly, but this calls into question the value of writing it in APL, I would say (for what it's worth, I believe Co-dfns is still not able to compile itself).

The phrase "allocate all intermediate arrays" seems fairly confusing: what's actually being allocated must be space for the pointers to these arrays and other metadata, not the data of the array itself. As the data is variable-size, it can't be fully planned out at compile time, and I'm fairly sure the register allocation is done when there's not enough shape or type information to even make an attempt at data allocation. This change can only improve constant overhead for primitive calls, and won't be relevant to computations where most of the work is on large arrays. I think it's helpful for Co-dfns in a practical sense, but not too exciting as it only helps with bad cases: if this is important for a user then they'd probably end up with better performance by switching to a statically-typed language when it comes time to optimize.

Constant lifting within the compiler is pretty cool, I'll have to look into that.

And if anyone wants an absolute masterclass in tacit programming, have a look at Aaron's Co-dfns compiler. The README has extensive reference material. https://github.com/Co-dfns/Co-dfns/

This always seemed like a very interesting project; we need to get to the point where, if things can run in parallel, they must run in parallel to make software more efficient on modern cpu/gpu.

It won't attract funds, I guess, but it would be far more trivial to make this work with an APL or a Lisp/Scheme. There already is great research for APL[0] and looking at the syntax of HVM-core it seems it is rather easy to knock up a CL DSL. If only there were more hours in a day.

[0] https://github.com/Co-dfns/Co-dfns

There are many styles of APL, not just due to its long history, but also because APL is somewhat agnostic to architecture paradigms. You can see heavily imperative code with explicit branching all over the place, strongly functional-style with lots of small functions, even object-oriented style.

However, given the aesthetic that you express, I think you might like https://github.com/Co-dfns/Co-dfns/. This is hands-down my favorite kind of APL, in which the data flow literally follows the linear code flow.

Which is, as far as I know, unused. (Similarly the gpu compiler.)

You might be familiar with iKe (grahics), SpecialK (GLSL) and Co-dfns. Also, I am working on bastardized APL for GPU – Fluent. Fluent 1 had backend implemented through Apple Metal Performance Shaders Graph and Fluent 2 has TensorFlowJS backend for now. I care more about having auto differentiation in the lang than running on GPU and do graphics, to be honest.

Not that I am aware of. I think the closest project is co-dfns[1] which is being developed by Aaron Hsu (he did a presentation as well). It aims to compile a subset of APL so that it can be executed on GPUs for instance, possibly with other backends. I imagine an XLA backend could be possible there.

[1] https://github.com/Co-dfns/Co-dfns

Aaron hsu did his dissertation on this topic (compiler, thesis), at indiana university in the us.