Jonas (Dec 19 2024 at 08:22): Jonas (Dec 19 2024 at 08:22):Hey, i really like how languages like Odin support Vector Math, i mean having Math Operator to Update Array Indizes. I don't know if it fits Roc but i just wanted to throw out the idea.
Norbert Hajagos (Dec 19 2024 at 08:48):There have been quiet a lot of discussions about it. Here is the most recent topic on it #ideas > static dispatch - operator desugaring to methods . Roc's historically been reserved to add operator overloading so that + would work on your custom matrix types, because it's easy to misuse that feature. But we all agree that it is nice for matrices, so (according to the plan) defining a plus function on a custom type will allow such thing. It's just that the type will have to be nominal (have to be declared with a name in a separate module, not created on a whim out of literals)
Sam Mohr (Dec 19 2024 at 08:53):Also, what @Norbert Hajagos would work for adding custom matrices, but without indexing syntax. E.g. even without custom data structures, there's no such thing is list[index] in Roc
Sam Mohr (Dec 19 2024 at 08:55):@Jonas could you give an example of what you'd want to be able to do? I presume list[index] += 3 is what you mean
Norbert Hajagos (Dec 19 2024 at 08:58):Ahh yes, no vec[idx] operator, since List is the base "array-like" collection, which isn't fix sized and there's always a bounds check, so it returns a result. We have no arrays, only tuples, but they are more like structs.
Jonas (Dec 19 2024 at 09:00):@Sam Mohr yes
Brendan Hansknecht (Dec 19 2024 at 15:25):Also, roc has no support for missing types. So no matrix plus scalar. I guess we could add it with static dispatch, but that is a separate idea
Ghadeer Abou-Saleh (Jul 13 2026 at 22:42):I am kinda partial to this idea as well. Although, to me it is not about array indices. CPUs have had support for SIMD instructions (that are meant for vectorization) for ages, and it is surprising to me that modern languages continue to ignore them (at least in their type systems and syntax).
Much like most languages have first class support for F32 and F64 primitive data types, why not also have first class F32x4 or F64x2 (and other up-to 128 or 256 bit primitive vectors)? As Jonas said, so far, I only heard of Odin supporting that, in addition to shading languages like GLSL, HLSL, and WGSL (which are for GPUs). It would be surprising to me if compiler backend IRs don't support them. WebAssembly does, I think.
Vector math would include component swizzling, dot/cross products, vector/vector, vector/matrix, and matrix/matrix multiplications. Maybe even quaternions can be thrown in as well.
Richard Feldman (Jul 13 2026 at 22:51):Ghadeer Abou-Saleh said:
I am kinda partial to this idea as well. Although, to me it is not about array indices. CPUs have had support for SIMD instructions (that are meant for vectorization) for ages, and it is surprising to me that modern languages continue to ignore them (at least in their type systems and syntax).
to paraphrase Boromir, "One does not simply add SIMD support to a language" :wink:
Richard Feldman (Jul 13 2026 at 22:53):if you want to enable all the SIMD algorithms, you have to add target-specific intrinsics.
Roc has never had a concept of target-specific anything.
Richard Feldman (Jul 13 2026 at 22:54):(well, Roc application code anyway. Platforms do at the host boundary and that's it.)
Richard Feldman (Jul 13 2026 at 22:56):so even if you sort out the type and intrinsic stuff, you're still looking at either introducing the concept of target-specific code to a language that's been carefully designed to be innately target-independent in every other way...or else add support for the lowest common denominator of SIMD that works across targets and will make a bunch of SIMD algorithms unimplementable
Richard Feldman (Jul 13 2026 at 22:58):and at the point where you're giving up the full range of SIMD algorithms that the target hardware supports, it's no longer obvious that SIMD intrinsics are worth it after all, as opposed to designs like ordinary builtin functions that always get inlined and then deterministically lower to SIMD operations.
Richard Feldman (Jul 13 2026 at 22:59):and that's without getting into things like whether (and if so how) to detect hardware support for things at runtime as opposed to, once again, aiming for lowest common denominator support
Richard Feldman (Jul 13 2026 at 23:01):if any of those had obvious answers, I'd be surprised that more languages didn't have native SIMD support...but given all that, I'm not at all surprised that only systems languages consistently support it today, because they're already doing intrinsics and target-specific stuff.
Richard Feldman (Jul 13 2026 at 23:04):another thing that a lot of older languages have to deal with is that many SIMD loads want data to have higher alignment than 16, and it's been common for decades to do all heap allocations with alignment of 16. That can make loads more complicated and costly to get right, which in turn hurts performance - which is a problem when the whole reason you're doing the SIMD thing at all is to get more performance.
Richard Feldman (Jul 13 2026 at 23:04):we already do per-allocation alignment, so that part isn't a problem for us.
Luke Boswell (Jul 14 2026 at 02:09):@Richard Feldman this might be a good candidate for https://www.roc-lang.org/faq
Luke Boswell (Jul 14 2026 at 02:12):The other related aspect of this is that the platforms can provide SIMD related things -- so it's not that Roc cannot provide first class support, it's just that it's domain specific and would need to be wrapped up in an API and tailored for that.
Luke Boswell (Jul 14 2026 at 02:13):So it's not in the builtins but there is nothing stopping a platform from supporting vector maths. I would imagine the Roc app provides a description to setup and run the transformations and then the platform executes that.
Arya Elfren (Jul 14 2026 at 09:34):Luke Boswell said:
I would imagine the Roc app provides a description to setup and run the transformations and then the platform executes that.
That sounds like some sort of linear algebra interpreter?
Arya Elfren (Jul 14 2026 at 09:34):I think there are some common candidates like this for interfaces that don't necessarily have to do with IO and that multiple platforms might want to support. e.g. wanting a web server platform but also the ffmpeg/video processing platform.
In the linear algebra case, some platforms would just implement matrix multiplication and others would import a BLAS library or call a GPU.
When it comes to intrinsics, the other option is tiny platform functions and hoping that LTO can inline the instructions (or some mechanism to guarantee that?).
Last updated: Jul 23 2026 at 13:15 UTC