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
Allow dynlinking code into ocamlc/opt #6696
Comments
Comment author: @gasche Where is the fork with french messages? |
Comment author: @alainfrisch I can see a lot of interesting uses for dynlinking code directly in the compiler. One obstacle is that Dynlink is not part of the stdlib. I'm personally in favor of including it, but there will be some resistance doing so, because (i) it is not supported in native code on all platforms (we can also have failing stubs, but the idea is that the stdlib should be fairly portable); (ii) the bytecode version of the Dynlink module draws with it some amount of dependencies (modules from the compiler), which might create technical issues (module name clashes), or, perhaps and legal ones (licensing -- I don't know how this is currently managed). Also, I'm not 100% sure about how Dynlink interacts with the toplevel. |
Comment author: @whitequark Would it not be possible to link Dynlink into the compiler without making it a part of the standard library, i.e. leaving it in the exact same place as it currently occupies? |
Comment author: @alainfrisch
Bootstrapping the compiler happens before otherlibs are built. If something is (i) available on all platforms and (ii) required by the compiler, it belongs quite naturally to the stdlib. |
Comment author: @lpw25
I would just like to point out that this bit is a very bad idea. Extending the type-checker correctly is very difficult. I worry this would lead to a proliferation of extensions that were fragile and/or unsound. In particular, people frequently suggest type-based meta-programming approaches, without understanding how fragile they are in the presence of inference and polymorphism. Experimenting with the type-checker is much better served by opam switches. |
Comment author: @whitequark I was thinking not as much about actually extending the type system as the minutae of the implementation. For example, adding custom match patterns would require some support from the typechecker--the equivalent of expanding extension nodes at Parsetree level that ppx extensions do. Otherwise, I agree. |
Comment author: @lpw25
I wonder whether it might be possible to provide more direct support for this use case. I haven't really had to deal with i18n stuff myself, but I assume there are some general approaches that people take. Something like the ability to specify a file filled with text for all the compiler's messages. |
Comment author: @whitequark C's gettext generally does what you say. However, such a tool does not currently exist for OCaml and even if it did, there would be arguments against inclusion of it in the compiler: it would be at least an additional build step and yet another parser for a data format with the messages. Personally, I find directly linking in the code to perform interpolation is the most straightforward way, and with least burden on the compiler maintainers. |
Comment author: @lpw25
If the file was a marshalled OCaml data structure then I don't think it would be very difficult. Just adding another "foo_format.mli" with the data structure and a read function, and a command-line argument to read in a file and use that data structure instead of the builtin one. Then packages could use compiler-libs to create the data structure and save it to a file in its "lib" directory, and ocamlfind would pass the file to the compiler when that package was used. |
Comment author: @whitequark Yes, that would work (although this is still more work than Dynlink.) Since I want Dynlink for other things as well--extensions of the code generator, loadable/custom backends, loading ppx inside the compiler, etc, etc, I'll continue to argue for Dynlink. Although if Dynlink is rejected from stdlib/compiler, this would be the route to take. |
Comment author: @whitequark @Frisch, I just noticed that we actually already have the failing primitives. byterun/unix.c is always present and it conditionally enables the body of caml_dlopen. I think this is a very good argument for moving Dynlink to stdlib. |
Comment author: @alainfrisch |
Original bug ID: 6696
Reporter: @whitequark
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2017-02-24T12:18:30Z)
Resolution: fixed
Priority: normal
Severity: minor
Target version: undecided
Fixed in version: 4.04.0
Category: ~DO NOT USE (was: OCaml general)
Related to: #6735
Monitored by: @Drup @bobzhang @gasche @diml @hcarty
Bug description
There can be several interesting uses of this, including, hopefully, eventually extending typechecker or code generator.
However, the immediately useful benefit is: by overriding the existing error message printers using Location.register_error_of_exn from a dynlinked module, it will be possible to support localized error messages without patching the compiler. Since the fork with French error messages is maintained for many years, this is clearly a desirable feature.
I propose to add a compiler flag whose value will be passed through Dynlink.adapt_filename and then Dynlink.loadfile.
The text was updated successfully, but these errors were encountered: