GHC supports dozens of type system extensions, which is great.
However, many of them come with their own syntax, which makes
separate switches hard to implement. One relatively mild
extension is support for existential types. Now, if we adopt the
debatable and debated convention that local type var
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
| > 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
> | 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
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
Loads of separate switches is great for finessing a build, but there will
still be a catch-call like -fglasgow-exts, right?
--
Andy Moran Ph. (503) 526 3472
Galois Connections Inc. Fax. (503) 350 0833
3875 SW Hall Blv
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
