Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006696OCaml~DO NOT USE (was: OCaml general)public2014-12-07 17:462017-02-24 13:18
Reporterwhitequark 
Assigned Tofrisch 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionundecidedFixed in Version4.04.0 
Summary0006696: Allow dynlinking code into ocamlc/opt
DescriptionThere 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.
TagsNo tags attached.
Attached Files

- Relationships
related to 0006735resolvedxleroy ocamlc -custom should not link to curses 

-  Notes
(0012703)
gasche (administrator)
2014-12-07 18:01

Where is the fork with french messages?
(0012704)
whitequark (developer)
2014-12-07 18:05

https://github.com/ocaml/opam-repository/tree/master/compilers/4.00.1/4.00.1%2Bfrench [^]
(0012711)
frisch (developer)
2014-12-08 10:14

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.
(0012712)
whitequark (developer)
2014-12-08 10:19

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?
(0012713)
frisch (developer)
2014-12-08 10:42

> 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.
(0012782)
lpw25 (developer)
2014-12-12 20:13

> 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.
(0012783)
whitequark (developer)
2014-12-12 20:16

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.
(0012784)
lpw25 (developer)
2014-12-12 20:27

> 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.
(0012785)
whitequark (developer)
2014-12-12 20:31

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.
(0012786)
lpw25 (developer)
2014-12-12 20:40

> 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.
(0012787)
whitequark (developer)
2014-12-12 20:57

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.
(0012829)
whitequark (developer)
2014-12-16 14:06

@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.
(0016073)
frisch (developer)
2016-07-13 18:00

https://github.com/ocaml/ocaml/pull/648 [^]

- Issue History
Date Modified Username Field Change
2014-12-07 17:46 whitequark New Issue
2014-12-07 17:47 whitequark Description Updated View Revisions
2014-12-07 18:01 gasche Note Added: 0012703
2014-12-07 18:05 whitequark Note Added: 0012704
2014-12-08 10:14 frisch Note Added: 0012711
2014-12-08 10:19 whitequark Note Added: 0012712
2014-12-08 10:42 frisch Note Added: 0012713
2014-12-12 20:13 lpw25 Note Added: 0012782
2014-12-12 20:16 whitequark Note Added: 0012783
2014-12-12 20:27 lpw25 Note Added: 0012784
2014-12-12 20:31 whitequark Note Added: 0012785
2014-12-12 20:40 lpw25 Note Added: 0012786
2014-12-12 20:57 whitequark Note Added: 0012787
2014-12-16 14:06 whitequark Note Added: 0012829
2015-01-08 23:45 doligez Status new => acknowledged
2015-01-13 22:56 doligez Target Version => 4.03.0+dev / +beta1
2015-01-13 23:47 whitequark Relationship added related to 0006735
2016-04-17 20:04 gasche Target Version 4.03.0+dev / +beta1 => 4.03.1+dev
2016-07-13 18:00 frisch Note Added: 0016073
2017-02-16 14:00 doligez Target Version 4.03.1+dev => undecided
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-02-24 13:18 frisch Status acknowledged => resolved
2017-02-24 13:18 frisch Fixed in Version => 4.04.0
2017-02-24 13:18 frisch Resolution open => fixed
2017-02-24 13:18 frisch Assigned To => frisch
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker