Stream: ideas

Topic: allow platforms to do arbitrary C FFI

Richard Feldman (Jan 06 2024 at 19:10):

splitting this off from #ideas > platform specific data structures

Brendan Hansknecht said:

It is arbitrary CFFI, but only for platforms.

Richard Feldman (Jan 06 2024 at 19:11):

so I think this idea is worth discussing, but I definitely think this would have major ecosystem implications (some maybe positive, some maybe negative)

Richard Feldman (Jan 06 2024 at 19:13):

for example, we've talked before about demand for LAPACK bindings, which is ~1.5K linear algebra functions implemented in about 600K LoC of FORTRAN plus inline assembly

Richard Feldman (Jan 06 2024 at 19:18):

so here is a sequence of events that could plausibly happen if we add this feature:

• someone makes a platform that does LAPACK bindings
• someone wants to build a library on top of it, so they request that someone use module params to make a general platform-agnostic "LAPACK bindings" interface, which individual platforms can implement. It has 1.5k functions in it, because that's how big LAPACK is.
• now various platform authors are pressured into implementing these bindings because that's the only way people can access it
• also, there are different versions of LAPACK, some people for their use case want BLAS instead of LAPACK, or possibly both, and platform authors are now getting pressured to compile several hundred thousand lines of FORTRAN into their host binaries, even if they would only be used by a small percentage of the platform's users
• a lot of platform authors say no to adding all that complexity for a small minority of use cases, so the people who really want those bindings say "fine, we'll fork the platform and add it ourselves" and now the ecosystem has basic-cli-lapack, basic-cli-lapack-v6.7, basic-cli-blas, basic-cli-blas-and-lapack, etc.
• as a consequence of this situation, now there is demand for arbitrary C FFI outside platforms just so we can get out of the platform mess

Richard Feldman (Jan 06 2024 at 19:20):

so on the one hand, it would be cool to unlock those use cases

Richard Feldman (Jan 06 2024 at 19:21):

on the other hand, I don't like the idea of platforms forking just for the sake of exposing a different mix of non-I/O C FFI things

Richard Feldman (Jan 06 2024 at 19:23):

the nice thing about I/O is that it all boils down to a small, finite set of OS syscall wrappers, and everything else is a convenience wrapper around that - so I/O doesn't have that potential "ecosystem explosion" problem, and it also doesn't have the problem of side-effecting functions claiming to not be side-effecting

Brendan Hansknecht (Jan 06 2024 at 19:24):

Couldn't this concern already happen just wrapped in tasks?

Brendan Hansknecht (Jan 06 2024 at 19:25):

Push to implement the full set of lapack tasks

Richard Feldman (Jan 06 2024 at 19:27):

totally, but the downside of having to do all math using tasks creates an incentive to port those functions to pure Roc instead, even if they're not quite as fast due to missing out on inline assembly optimizations (but then again, the Task state machine probably has more overhead, so the pure Roc ones might actually be faster than that in practice)

Richard Feldman (Jan 06 2024 at 19:28):

the outcome I would want to see is that we end up with pure Roc linear algebra libraries that are fast enough in practice for the use cases where people would want LAPACK or BLAS

Richard Feldman (Jan 06 2024 at 19:29):

and I think it's healthy that the way FFI works today creates an incentive structure that rewards someone for doing that

Brendan Hansknecht (Jan 06 2024 at 19:29):

I think that's fair, but I think it greatly hurts the ability to interface with and interact with many types.

Richard Feldman (Jan 06 2024 at 19:30):

so I have to admit, I don't totally understand why that would be

Brendan Hansknecht (Jan 06 2024 at 19:31):

For example, say i have a c platform that already uses Blas or lapavk and i want to move some code into roc. I need that roc code to directly work on the Blas/lapack types. So I am stuck using tasks for everything and It makes things clunky enough that roc probably isn't work using.

Richard Feldman (Jan 06 2024 at 19:31):

I guess if I'm sending a data structure from the host to the platform which uses unions and/or pointer packing and/or needs to do unsafe pointer dereferencing a lot becuase bounds checks are too expensive?

Brendan Hansknecht (Jan 06 2024 at 19:32):

In general think about any sort of embedding case where roc is not the main language, it is just a plugin language. The main project will not contort itself to use roc types. Roc needs to be able to use the host types.

Brendan Hansknecht (Jan 06 2024 at 19:33):

No one is going to rewrite bevy to internally use roc types, but someone might enjoy writing a roc plugin that uses the existing bevy types.

Richard Feldman (Jan 06 2024 at 19:34):

yeah I appreciate that :thumbs_up:

Brendan Hansknecht (Jan 06 2024 at 19:35):

That is the main use case we want to enable. I am not sure how to enable It without also enabling generic ffi.

Richard Feldman (Jan 06 2024 at 19:36):

I'm curious what your thoughts are on the LAPACK example concern

Richard Feldman (Jan 06 2024 at 19:37):

e.g. do you think it's a significant concern but worth it if it happens? or don't think it's a significant concern in practice? (like it would be fine if that happened)

Richard Feldman (Jan 06 2024 at 19:37):

or it would be bad, but worth it for the sake of enabling more use cases

Richard Feldman (Jan 06 2024 at 19:39):

another point to consider: a platform which offers (for example) functions for synchronous global mutable state access, and then that gets popular and a significant portion of the library ecosystem is built around requiring that

Richard Feldman (Jan 06 2024 at 19:39):

for example, someone would probably do that to get locale and also for synchronous random number generation

Brendan Hansknecht (Jan 06 2024 at 19:47):

Hmm...yeah, i guess this plus module params makes everything a lot more concerning cause It enables Amy library to explicitly depend on many things that should be effects.

Richard Feldman (Jan 06 2024 at 19:53):

yeah

peeps (Jan 06 2024 at 20:41):

So I didn't want to fill this thread with my nooby questions or nooby suggestions, but I had an idea while DMing Brendan which is worth mentioning here:

What if we just prevented "FFI Modules" from being injected? Could we not just make an exception in the implementation of module params? And then later figure out how it could still be implemented while also mitigating abuse use cases, if people really want it. It might not come up as a requirement at all.

Brendan also mentioned that this "would need to be a recursive check. No function that calls and FFI function can be injected".

Richard Feldman (Jan 06 2024 at 20:46):

also module params are essentially syntax sugar

Richard Feldman (Jan 06 2024 at 20:47):

you can always have your functions take an extra argument, namely another function which the caller provides

Richard Feldman (Jan 06 2024 at 20:47):

(module params essentially do that for you behind the scenes)

Richard Feldman (Jan 06 2024 at 20:49):

so people could still implement side effecting functions, they'd just have to take an extra argument :sweat_smile:

Brendan Hansknecht (Jan 06 2024 at 23:12):

For sure, but at least It would be a much bigger hassle which would hopefully reduce how often It happens

Brendan Hansknecht (Jan 06 2024 at 23:14):

Like might be enough to avoid It becoming common, but yeah, not a true guarentee at all.

peeps (Jan 07 2024 at 18:48):

I don't know much about this topic, but how much code analysis could we do on the code that every C capable language compiles to? Like I could theoretically look at a Rust method or function and just say "if all these parameters are immutable, then this function is pure". We obviously don't want do that on a per language basis, but If you could do that on the bit code or generated C (maybe we can make sure certain opcodes are not present), then we could automatically enforce purity laws at compile time.

Sky Rose (Jan 07 2024 at 21:03):

That'd be hard, and also the motivation for this idea is to allow platforms to use impure implementations as long as they provide a pure interface.

peeps (Jan 07 2024 at 21:12):

Sky Rose said:

That'd be hard, and also the motivation for this idea is to allow platforms to use impure implementations as long as they provide a pure interface.

Oh thats interesting, im not familiar with functional programming (Roc would be my first tbh) so what would a pure interface look like?

Kevin Gillette (Jan 07 2024 at 22:46):

The lapack example, and the plausible sequence of events that @Richard Feldman listed, would suggest we would benefit from having some way to integrate with [pure] libraries without requiring support from the platform.

Chris Wesseling (Feb 26 2024 at 23:21):

peeps said:

Oh thats interesting, im not familiar with functional programming (Roc would be my first tbh) so what would a pure interface look like?

Roughly put: pure functions can be memoized. If you (given enough memory) could implement the function as a table lookup, it's pure. A table lookup always returns the same value for the same parameter and it doesn't change the parameter.

Last updated: Jun 16 2026 at 16:19 UTC