(ffi "foo(%1)" :: Text -> Char) "Hello!"
This also makes writing libraries interoperating generically with foreign code much easier. For example currently the language-c-inline library needs some inconvenient TH machinery to refer to the C functions it creates on the fly when processing a module with inline C. This machinery would not be needed if we had anonymous FFI imports.
We propose to extend the language syntax so that anonymous FFI imports can appear in ordinary Haskell expressions, like so:
Where fimport and fanonspec are patterned against the already existing fdecl and fspec, respectively. It might be worth thinking about factoring out the common parts between top-level and anonymous FFI.
This allows to use all the existing top-level FFI import facilities in an anonymous manner, by reusing the existing FFI import syntax without the naming.
The code in TcForeign.hs already handles type-checking of top-level FFI imports, and said code can be imported wholesale with little modification to type-check anonymous FFI imports. Obviously type-checking of anonymous FFI imports will not cause the binding of any name.
FFI imports are already desugared to a ordinary Haskell functions. For example the already mentioned
Thus, all that needs to be done is take the desugaring code in DsForeign.hs and adapt it to produce the same code, inline, for anonymous FFI imports.
For this reason, after we implement anonymous FFI imports as described we plan to extend them to be able to accept the location of the code at runtime, as a standard Haskell expression.