ghc_extra_opts in package

Simon Marlow simonmar@microsoft.com
Thu, 28 Jun 2001 10:16:46 +0100


> > Another issue is that it turns out to be hard to enable certain
> > extensions without enabling others, because it requires you to pass
> > around more state in the compiler, and in particular in the parser
> > (the number of different languages being parsed increases), which is
> > why we lump all the extensions together in GHC.  However, I agree
> > the situation isn't ideal.
>=20
> So here's a concrete suggestion:
>=20
> 1) We standardise the definition of various extensions (mptc,=20
> unboxed types,
>    etc.) so that if two compilers both claim to support=20
> feature X, then
>    they accept the same code.  (We're pretty close to this already.)

Definitely - this has been a goal for a while.  I think there was a plan
to have a section on www.haskell.org listing all the extensions with
their specifications.

> 2) We extend the package definition with a list of features=20
> used in the
>    package.
>=20
>    Package {
>      name =3D "net",
>      extensions =3D [ "FFI", "ExceptionHandling", ... ],
>      ...
>    }

Let's be clear: these extensions are those required by the *consumer* of
the package, right?  The implementation of the package will likely
require a different (probably super-) set of extensions.  For example:
"FFI" isn't typically required by the consumer of the "net" package, but
it is certainly used in the implementation.

Also, this doesn't mesh well with the portability notion in the new
libraries proposal.  The idea there is that certain libraries would be
optional depending on whether the compiler implemented certain
extensions - with your scheme this would have to be done at the package
level.  I wanted to lump all the core libraries into a single package on
GHC, but this would mean that package "core" for GHC would require a
different set of extensions than the same package for NHC.

Cheers,
	Simon