Question: what is the bottom line for native code?

[bluddy]

I understand that splicing currently requires saving temporary cmo-like files. Does that mean that the final native code currently calls out to bytecode, or is the AST eventually integrated seamlessly into the native code?

[OlivierNicole]

The final native code is the same as if macros had been expanded "by hand" and then the final source code had been compiled to native code (second option in your message). So no performance loss in the final code.

The macros themselves, however, are compiled to bytecode; so the compiler calls out to bytecode to perform macro expansion. This may be a problem for you if your macros need to run fast. On the other hand, it is particularly handy for cross-compilation, since the platform on which macro expansion is performed can be different from the target platform.

I hope that's clear, otherwise do insist.

[Ericson2314]

On the other hand, it is particularly handy for cross-compilation, since the platform on which macro expansion is performed can be different from the target platform.

Wait, which platform affects the semantics of macros? I'd expect macros be for the build platform (of the code being built; host platform from the compiler's perspective) and the final compiled code to be the for the host platform (target from compiler's perspective).

[OlivierNicole]

Macros are run by the compiler, so macros run on the build platform. But since macros are compiled to bytecode it doesn't really matter.

[Ericson2314]

Great! Forgive me for not knowing this, but the bytecode interpreter still has some support for FFI, right? Then it would certainly matter as certain foreign functionality may not be available on the host platform.

[I do not know the answer to this basic question because I am a Haskeller mainly interested in this in hopes that it avoids all the mistakes Template Haskell made outlined in http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/. It would be wonderful to point to this as precedent for exactly what needs to be done 😄]

[OlivierNicole]

Fortunately, Racket and that blog post are one of the designers' inspirations for OCaml macros ☺

Yes, supporting foreign function calls implies the availability of object files for the build platform. Also, we do not support calls to non-standard foreign primitives in static code yet. While it would be easy to add support for this in natively-compiled versions of the compiler (ocaml*.opt), I'm not sure about what can be done for the bytecode-compiled compilers. Cc @yallop @lpw25?

[lpw25]

While it would be easy to add support for this in natively-compiled versions of the compiler (ocaml*.opt), I'm not sure about what can be done for the bytecode-compiled compilers.

Foreign primitives work with both bytecode and nativecode, so these should work fine.

IIRC there are some (bytecode-only) systems which do not support dynamically loading C code, they might have some issues for the current bytecode version which dynamically loads macro code into the compiler. Although I'm not sure that these systems still exist or are still considered supported.