Export restrictions :) Re[4]: Pickling a finite map (Binary + zlib) [was: [Haskell-cafe] Data.Binary poor read performance]

Bulat Ziganshin bulat.ziganshin at gmail.com
Tue Feb 24 07:56:06 EST 2009

Hello Svein,

Tuesday, February 24, 2009, 3:47:44 PM, you wrote:

>> btw, i always thought that it should be a way to overcome any export
>> lists and go directly to module internals. limiting export is the way
>> to protect programmer from errors, not security feature, and it should
>> be left to programmer to decide when he don't need it. compilers
>> should just be able to check whether some module/library imported
>> abstractly or with internals too. this will render useless all those
>> .Internals modules that now we need to add everywhere
> I agree in principle, but GHC also uses that knowledge to optimize the
> code better - if a function is exported it has to produce the most
> polymorphic possible code for its type, if it isn't it can specialize
> better... that sort of thing.

> So it's not for security purposes, it's for technical reasons; you
> can't override the export list externally because the information
> you'd need to use the functions simply doesn't exist.

well, obvious answer is that ghc should optimize according to export
specs AND add original function definition to the .o file

Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com

More information about the Haskell-Cafe mailing list