-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: what is the bottom line for native code? #10
Comments
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. |
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). |
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. |
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 😄] |
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 ( |
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. |
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?
The text was updated successfully, but these errors were encountered: