Structuring Arrays with Algebraic Shapes

56 todsacerdoti 4 6/27/2025, 7:55:26 PM dl.acm.org ↗

Comments (4)

bloaf · 32m ago
This is great. For a long time I've had a gut feeling that there must exist a synthesis between pure functional, array, and data-oriented programming that gives you the best of all worlds:

Type safety, concise-to-the-point-of-terse code (with the types helping humans read it), and very high performance.

And this feels like a step in the right direction.

iamdamian · 2h ago
This looks pretty compelling to me. I've been itching for a math-friendly language that makes it easy to work with arrays, vectors, vector spaces, manifolds, etc., but takes advantage of static typing. (Haskell is amazing but doesn't quite make linear algebra constructs feel native.)

On first read, it looks like this is designed with a healthy balance between mathematical insight (relationship of product types and tuples, basis in lambda calculus) and real developer needs (e.g., static typic is nice; dependently typed systems can be too much; types are great, but "nameless shapes" are useful, too).

I'd love to see an implementation of this to play around with.

mamcx · 1h ago
Can't find a repo of this lang...

Is compelling to me because I'm in the hunt for marry array + relational (https://tablam.org)

b0a04gl · 2h ago
> naming axes gives semantic weight to array shapes, but it also introduces commitment. like in practice, array shapes mutate fast : reshape, squeeze, permute half these ops aren't semantic, they're just cleanup to fit the next layer. adding names to that doesn’t simplify, that adds bookkeeping.

> also naming means locking intent early. once you say 'this axis is time', every downstream op inherits that label, even if that dim gets folded or split.

it's tradeoffs only