FFI?

[gnumonik]

We need to figure out what we're going to do for the FFI. Most importantly: Do we need FFI support?

I don't have a clear ideas here. If we do want to support an FFI, the foreign imports should probably be in the same language as the compiler output (e.g. PIR or UPLC or TPLC). But those aren't really languages anyone really writes code in.

[klntsky]

We should target the lowest level of the abstraction hierarchy, that is UPLC, so that we can interop with any language in the future. If we don't, PIR FFI would be useless, as no one outputs it.

It is not clear how can we represent UPLC "blobs" in PIR during compilation, however. Could you please check if it is an option?

[klntsky]

We had a talk about this via voice.

We can't have FFI without the I, which means that there must be a well-defined standard of UPLC layout for "UPLC libraries" before we can make them usable in the language. This is something that doesn't exist yet.

For future reference, we considered the following use case:

• we have a cryptographic library written in Plutus
• we want to use it in Purus
• ???

There are two options:

including it via FFI as UPLC

We must know the layout of its interface AND have FFI as a language feature.

passing it as argument in some form

We can define the layout e.g. using an array of functions and simply assert that the validator is a script that accepts an extra argument. Then we can "link" the library to the main program with simple plutus parameter application. Sadly, it is different from applying PlutusData, because we want to pass functions as well. But in general it must not be that difficult, just AST manipulation.

[klntsky]

For now we will just skip FFI support until there is a real use case.