Co-dfns VS chapel

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/

I don't put a lot of stock in the "write-only" accusation. I think it's mostly used by those who don't know APL because, first, it's clever, and second, they can't read the code. However, if I remember I implemented something in J 10 years ago, I will definitely dig out the code because that's the fastest way by far for me to remember how it works.

This project specifically looks to be done in a flat array style similar to Co-dfns[0]. It's not a very common way to use APL. However, I've maintained an array-based compiler [1] for several years, and don't find that reading is a particular difficulty. Debugging is significantly easier than a scalar compiler, because the computation works on arrays drawn from the entire source code, and it's easy to inspect these and figure out what doesn't match expectations. I wrote most of [2] using a more traditional compiler architecture and it's easier to write and extend but feels about the same for reading and small tweaks. See also my review [3] of the denser compiler and precursor Co-dfns.

As for being read by others, short snippets are definitely fine. Taking some from the last week or so in the APL Farm, {⍵÷⍨+/|-/¯9 ¯11+.○?2⍵2⍴0} and {(⍸⍣¯1+\⎕IO,⍺)⊂[⎕IO]⍵} seemed to be easily understood. Forum links at [4]; the APL Orchard is viewable without signup and tends to have a lot of code discussion. There are APL codebases with many programmers, but they tend to be very verbose with long names. Something like the YAML parser here with no comments and single-letter names would be hard to get into. I can recognize, say, that c⌿¨⍨←(∨⍀∧∨⍀U⊖)∘(~⊢∊LF⍪WS⍨)¨c trims leading and trailing whitespace from each string in a few seconds, but in other places there are a lot of magic numbers so I get the "what" but not the "why". Eh, as I look over it things are starting to make sense, could probably get through this in an hour or so. But a lot of APLers don't have experience with the patterns used here.

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

[1] https://github.com/mlochbaum/BQN/blob/master/src/c.bqn

[2] https://github.com/mlochbaum/Singeli/blob/master/singeli.bqn

[3] https://mlochbaum.github.io/BQN/implementation/codfns.html

[4] https://aplwiki.com/wiki/Chat_rooms_and_forums

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.

Thanks, @subharmonicon!

While Chapel can run on many different systems, the main goal is making HPC programming much easier. Therefore, we are currently focusing on hardware that you can find in HPC systems (NVIDIA, AMD and Intel). Metal doesn't fall into that category, unfortunately. So far, the name came up infrequently in our discussions IIRC (especially targetting SPIRV), but we haven't heard from any [potential] user who may be interested in it. I would encourage you or anybody else interested in it to create an issue asking for the feature: https://github.com/chapel-lang/chapel/issues/new. Seeing public interest in that direction can change our prioritization.

One thing that I wanted to add that's not in the blogpost is the "cpu-as-device" mode. With that mode, you can use any machine, even one without a GPU, to write applications using Chapel's GPU features. That mode is for those who want to do initial development/debugging on their personal laptops before putting their application on an HPC system. In other words, while you can't use Metal directly, you can still write GPU-enabled applications in your Mac using Chapel, if the end goal is to run it on an HPC system. More details on cpu-as-device: https://chapel-lang.org/docs/main/technotes/gpu.html#cpu-as-...

Agreed. Here is a serious contender[0] minus all the hype and the $100M in VC money. You would expect a minimum of interest given how Mojo is received by the community, but not really in practice.

[0]: https://chapel-lang.org/

Cray is pushing their own language as well, Chapel.

https://chapel-lang.org/

As for Julia on Cray,

"Julia — The Newest Petaflop Family Language We Have Started to Love"

https://www.avenga.com/magazine/julia-programming-language

> Julia is one of the few languages that are in the so-called PetaFlop family; the other languages are C, C++ and Fortrant. It achieved 1.54 petaflops with 1.3 million threads on the Cray XC40 supercomputer.

https://chapel-lang.org if possible, Nix was also recently mentioned in Chapel Workshop https://chapel-lang.org/CHIUW2023.html https://github.com/twesterhout/nix-chapel

See Val for a possible step into that direction.

https://www.val-lang.dev/

Or how the Chapel language for HPC is going at it,

https://chapel-lang.org/

I suggest posting to a PLT focused resource, such as http://lambda-the-ultimate.org/

That said, a bit confused about the languages you reference in this context (Python, C#, JS) - didn't see any mention here or at your github repo of languages (some relatively ancient) in this space designed.

Sandia: Programming Languages for HPC [high performance computing] - is there life after MPI?

https://www.sandia.gov/app/uploads/sites/179/2022/04/SOS10-T...

Chapel:

https://chapel-lang.org/

https://en.wikipedia.org/wiki/Category:Array_programming_lan...

We needed the implicit conversion to `uint` in order for the overload resolution rules to make reasonable choices when faced with binary overloads for all of the numeric types. The document I linked talks through the examples. The case we were facing is something that we shared with `C#` -- in `C#` terms, if I make overloads for `f` for all numeric types (see https://github.com/chapel-lang/chapel/blob/main/test/types/coerce/allNumericsBinary.cs if you want to know exactly what I am talking about), then `f( myInt, myUlong )` runs `f(float, float)` which makes no sense. Especially if you care about numerical accuracy or program performance.

Code | Blog Walkthrough