> Unison does not currently support a Foreign Function Interface, for invoking code written in other languages.
> Your programs can interact with the outside world via the `IO` ability, and this includes interaction via network sockets - so you can interact with code written in other languages if that code can expose a network interface, for example as a web service. We'd like to improve on this position in the future.
So far so good, I guess. They're trying to do something that makes sense in the future.
They then go on to outline how they're apparently going to expose specific parts of what you might want to use, like `GPU` as an ability/effect...? What do I do when I just want to execute some of my C code and don't want to jump through hoops to do so? I get that this maybe falls apart entirely because of the idea of content-addressable functions, but can't an FFI binding be the hash of its name and inputs and output or something?
Maybe I'm misunderstanding their plan with regards to FFI solutions. In the end I'd like to just have something like this with both static and dynamic libraries:
ModuleName = foreign import c [libmodule.a, otherlib.so]
ModuleName.OpaqueCoolType a = OpaqueCoolType a
ModuleName.has : a -> OpaqueCoolType a -> Bool
Hi, one of the Unison creators here. We've held off working on FFI until the JIT compiler[1] is completed since FFI is closely connected to the runtime.
There's some interesting subtleties with FFI in a distributed programming language, so I'll ramble about that here in case it's interesting to you. :)
So, in Unison, all values are serializable, including functions and their dependencies. This is a key superpower that enables a lot of the neat stuff we do. As long as those functions are written in pure Unison, we can easily serialize them, deploy them on the fly, etc. But when we add an FFI, the story changes - the sender may have some C library in their environment, and that library may not exist at the recipient node. The two nodes could be different platforms, one Mac, one Linux, and the library may have been written specifically for Linux, say!
So when we add FFI, we will likely be doing it in a different way than most languages. Functions that use FFI will have this tracked in the their type, using our effect system. You'll be able to use whatever C libraries you want in your local computations, but if you want to sent those values around, you need to be sending them to a place that supports that same set of FFI effects, since the C library and its dependencies can't literally be deployed on the fly in the same way as pure Unison code. In our cloud platform, nodes are typed based on what effects they support and we'll probably add a way to create new node pools that have access to whatever C libraries you want.
In "regular" programming, we're not used to thinking about "the execution environment" as a thing that's represented explicitly within the program. Instead, there's an assumed execution environment (which includes the set of native libraries, etc) and you get runtime errors if you run a program and some of the assumed execution environment is missing (like a shared library, say). For the most part, people have been okay with this, but it's already somewhat of a problem for languages that target the browser and the backend. The language may be statically typed, but now the type system is not tracking some key information - namely, is this a function I can call here (if I'm expecting this code to compile to JS) or is it a function that only can be called for backend code? In a distributed setting with heterogeneous nodes with different capabilities, this problem is even more pronounced, which is why we track this information in the types and plan to do so once we add FFI.
It's definitely interesting. I'm happy to hear that you'll definitely be supporting what we can currently do with less rigid languages and their FFI, but that we'll have to adapt to the bounds of the system and its rules to some extent.
Do you have any idea how you'd support `LoadLibrary`/`dlopen` in order to load/reload function pointers live? At some point I imagine a lot of this has to have a "trust me" kind of escape hatch.
https://www.unison-lang.org/docs/usage-topics/general-faqs/#...
> Unison does not currently support a Foreign Function Interface, for invoking code written in other languages.
> Your programs can interact with the outside world via the `IO` ability, and this includes interaction via network sockets - so you can interact with code written in other languages if that code can expose a network interface, for example as a web service. We'd like to improve on this position in the future.
So far so good, I guess. They're trying to do something that makes sense in the future.
They then go on to outline how they're apparently going to expose specific parts of what you might want to use, like `GPU` as an ability/effect...? What do I do when I just want to execute some of my C code and don't want to jump through hoops to do so? I get that this maybe falls apart entirely because of the idea of content-addressable functions, but can't an FFI binding be the hash of its name and inputs and output or something?
Maybe I'm misunderstanding their plan with regards to FFI solutions. In the end I'd like to just have something like this with both static and dynamic libraries: