The Foreign Function Interface (FFI for short) is a mecanism proposed by many programming languages which is used to link programs written in two different programming languages together through the use of a common ABI.
The most common FFI in programming languages nowadays is one targetting the C ABI, but some also exist for JS (e.g. Koka or Purescript), C# (Koka), Java (we may add Scala and other JVM-targetting programming languages there), etc.
The grammar itself is very simple:
- Foreign exports are indicated with the meta-attribute
export on any top-level let-bound function/global variable.
- Foreign imports are created using
#[import "header.h" fun-name] val fun : type where the header name "header.h" is optional.
Foreign functions cannot have effects (this doesn't mean they are pure! this only means they need to be encapsulated on the Zilch-side to create side-effects, e.g. in effect hgandlers) and cannot either be exported by modules, as their use is strictly unsafe.
That way, unsafe FFI-defined function cannot escape a module by accident, which would lead to unsafe codebases using this module.
Semantics are left undefined for now because an ABI will have to be defined.
The Foreign Function Interface (FFI for short) is a mecanism proposed by many programming languages which is used to link programs written in two different programming languages together through the use of a common ABI.
The most common FFI in programming languages nowadays is one targetting the C ABI, but some also exist for JS (e.g. Koka or Purescript), C# (Koka), Java (we may add Scala and other JVM-targetting programming languages there), etc.
The grammar itself is very simple:
exporton any top-levellet-bound function/global variable.#[import "header.h" fun-name] val fun : typewhere the header name"header.h"is optional.Foreign functions cannot have effects (this doesn't mean they are pure! this only means they need to be encapsulated on the Zilch-side to create side-effects, e.g. in effect hgandlers) and cannot either be exported by modules, as their use is strictly unsafe.
That way, unsafe FFI-defined function cannot escape a module by accident, which would lead to unsafe codebases using this module.
Semantics are left undefined for now because an ABI will have to be defined.