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

[Bulat Ziganshin]

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