On Tue, Apr 17, 2012 at 10:25:10PM +0200, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 17.04.2012, 22:17 +0200 schrieb Iustin Pop: > > On Tue, Apr 17, 2012 at 04:06:25PM -0400, Michael Alan Dorman wrote: > > > Iustin Pop <iustin@debian.org> writes: > > > > As far as I understand, it's not symbol mangling, but the fact that > > > > dynamic linking (without recompilation) prevents the optimiser from > > > > doing its full work (e.g. inlining across modules, etc.). > > > > > > Err, now I could be wrong, but I didn't think GHC was doing link-time > > > optimization---and if it's not, ISTM that inlining across modules, > > > whether static or dynamic is infeasible, no? > > > > I might be wrong, but as far as I understand it, it's not link-time > > optimisation, but rather compile time. If the library exports an > > (inlinable) function, and ghc decides to inline it, then the program > > will get the inline copy. So in this mode, it is across modules. > > > > Of course, I could be very wrong :) > > you could, but you are not :-). This is exactly what happens. Glad to hear :) > And note that the inlined code of course uses the rest of the exposing > module „from the inside“ and may, for example, use non-exported > function. Therefore even changing the internals of the module will > change the interface. Oh, now this I didn't know, thanks for the explanation, and it is very important indeed. iustin
Attachment:
signature.asc
Description: Digital signature