Simon Marlow
Let's be clear: these extensions are those required by the *consumer* of the package, right?
Blink! I hadn't been thinking of it that way. For a binary package, I guess that is all it means but it seems that a source package could/should distinguish between which flags you need to compile the code and which to compile against it.
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.
Hmmm, my mental model of packages was a group of tightly coupled modules so I wasn't making this distinction.
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.
That's more because of conditional compilation than the library/package distinction right? Hmmm, conditional compilation complicates the story for source packages. Choices: o one package per combination of cpp flags o one package with some sort of conditionals inside it: deps = case COMPILER of __GHC__ => net, lang __NHC__ => lang __HUGS__ => greencard Neither is very appealing. Is there an existing story for this sort of thing? -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/ ps I've been thinking that we should add conditional compilation to the list of extensions (but with the intention that all compilers would support it). I'm thinking all we need and want is conditional compilation but #define's would be restricted to a config file (maybe) and macro expansion would be limited to the expression part of #if. I think this is what Marcin put in hsc2hs so maybe he can comment?