| It is sad that the usage of libraries containing polymorphic code | [...] | seems to imply runtime overheads, by preventing specialisation.

I agree that it is sad. The only way around it is to ship libraries with *all* their source code (perhaps hidden in the interface file). That could be done, but it'd be Real Work

One way of tackling it would be to change ghc so that compilation doesn't produce .o files containing machine code but, rather, files containing a concise encoding of STG code. One possible concise encoding would be as bytecodes. (With just a little care over their design, you can easily uncompile bytecodes to recover the original code so we're not losing any information.) Obviously, ghci could interpret this code directly but it would take little more work to have ghci compile the bytecode to machine code. There's been lots of research into how to do this effectively by both the Forth and the Java communities. This case ought to be easier because STG code has already had a very powerful optimizer applied to it so all that's left is doing a good job with register allocation and pipelining. That same compilation engine could also be used in linking: read a bunch of bytecodes, compile to machine code, write out a .o file to be linked against the runtime and any C libraries. The 'unoptimized, portable' variant of this could either generate C code for compilation by gcc or, easier still, leave them as bytecodes and include a bytecode interpreter in the system. Benefits: I think the result would be more portable (because there is always the interpreter to fall back on). Instead of the ghc folks shipping a bunch of .hc files for porting purposes, they would ship a load of bytecode files. [Of course, it won't eliminate all porting issues: Windows and Solaris differ in more ways than just their processor...] This technology would support things like template Haskell and persistence research nicely. An optimizer can easily get hold of any source code it needs by dipping into the compiled files when it wants and decompiling the bytecodes. Of course, none of this negates Simon PJ's comment that it would be Real Work. -- Alastair Reid