On Wed, 25 Jun 2003 10:18:17 +0100
Alastair Reid <[EMAIL PROTECTED]> wrote:
> > | 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 li
Alastair Reid writes:
> 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.
Yes, one could indeed do that. We've discussed various schemes like
this in the past
> | 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
| > The only workaround is to define T early,
| > import it into A, and specialise A.f there.
|
| What if A is a pre-defined module, say FiniteMap?
| Then I can't change its source text. (Which isn't even there.)
| (Of course, I can grab it from the source distribution.)
|
| It is sad that the us
Simon, thanks for the information on SPECIALISE pragmas.
> The only workaround is to define T early,
> import it into A, and specialise A.f there.
What if A is a pre-defined module, say FiniteMap?
Then I can't change its source text. (Which isn't even there.)
(Of course, I can grab it from the s
| I am looking for some advice on
| where to place specialize-pragmas for ghc
| (to optimize speed - and heap usage)
|
| Typically I have some module A (containing polymorphic functions A.f,
..)
| and a module B uses this. The interesting case is
| when I want to specialize A.f (which is NOT expor
