You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 6725 Reporter:@alainfrisch Status: closed (set by @alainfrisch on 2016-12-08T16:19:20Z) Resolution: won't fix Priority: normal Severity: feature Target version: later Category: standard library Tags: patch Related to:#6790 Monitored by:@whitequark@gasche@jmeber@hcarty
Bug description
The (bytecode) Dynlink module drags a lot of compiler internal modules with it (they are packed into a Dynlinkaux module included in dynlink.cma). It seems that with some little refactoring, one could get rid of many of these dependencies. For instance, Lambda is required only because of its structured_constant type (---> one could move this definition to somewhere else, or "evaluate" structured constants into Obj.t values put in .cmo files). Fundamentally, there does not seem to be a deep reason for requiring e.g. subst.cmo, terminfo.cmo or ast_mapper.cmo in Dynlink...
Reducing dependencies will reduce binary code size and improve the structure of the source code; more importantly, it might facilitate the inclusion of dynlink in stdlib at some point (and thus its potential use in the compiler itself).
As a side remark, I'm wondering about the license on the dynlink library (the code under otherlibs is supposed to be under LGPL, but the library embeds modules from "the Compiler", which is under QPL).
I've uploaded a patch that evaluates structured constants before putting them in .cmo file (and thus simplify the life of the (dyn)linker). Possible disadvantages of doing so: (i) more difficult to print the constant in the dumpobj tool; (ii) float literals are evaluated at compile time, not link time, which might give slightly different results with dynlink, if the program is compiled and executed on different platforms; (iii) remove some opportunities for sharing constants at link time (we don't do it currently anyway).
Original bug ID: 6725
Reporter: @alainfrisch
Status: closed (set by @alainfrisch on 2016-12-08T16:19:20Z)
Resolution: won't fix
Priority: normal
Severity: feature
Target version: later
Category: standard library
Tags: patch
Related to: #6790
Monitored by: @whitequark @gasche @jmeber @hcarty
Bug description
The (bytecode) Dynlink module drags a lot of compiler internal modules with it (they are packed into a Dynlinkaux module included in dynlink.cma). It seems that with some little refactoring, one could get rid of many of these dependencies. For instance, Lambda is required only because of its structured_constant type (---> one could move this definition to somewhere else, or "evaluate" structured constants into Obj.t values put in .cmo files). Fundamentally, there does not seem to be a deep reason for requiring e.g. subst.cmo, terminfo.cmo or ast_mapper.cmo in Dynlink...
Reducing dependencies will reduce binary code size and improve the structure of the source code; more importantly, it might facilitate the inclusion of dynlink in stdlib at some point (and thus its potential use in the compiler itself).
As a side remark, I'm wondering about the license on the dynlink library (the code under otherlibs is supposed to be under LGPL, but the library embeds modules from "the Compiler", which is under QPL).
File attachments
The text was updated successfully, but these errors were encountered: