Skip to content
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

Closed
vicuna opened this Issue Dec 7, 2014 · 13 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

vicuna commented Dec 7, 2014

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 7, 2014

Comment author: @gasche

Where is the fork with french messages?

@vicuna

This comment has been minimized.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 8, 2014

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 8, 2014

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?

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 8, 2014

Comment author: @alainfrisch

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?

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 12, 2014

Comment author: @lpw25

There can be several interesting uses of this, including, hopefully, eventually extending typechecker

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 12, 2014

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 12, 2014

Comment author: @lpw25

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 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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 12, 2014

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 12, 2014

Comment author: @lpw25

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.

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 12, 2014

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 16, 2014

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Jul 13, 2016

Comment author: @alainfrisch

#648

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.