[Hugs maintainer (Johan) added to list]
Writing about providing compiler-specific flags in package
descriptions, Simon Marlow <[EMAIL PROTECTED]> writes:
> According to the Principle of Least Astonishment, we should
> force the user to add any extra options himself, because if
> '-package wibble' automatically adds a number of
> language-feature options then it's just too magical and
> non-obvious.
> On the other hand, I presume you *need* these options in
> order to be able to use Docon, so adding them automatically
> would seem reasonable.
> Opinions, anyone?
I see 3 issues here:
1) The extra options may enable non-standard language features required
to compile the code and/or used in the API.
This seems entirely cool.
If the extensions are visible in the API, the user already knows
about them and will know to add the same flags when compiling their
code.
If the extensions only show up in .hi files, the compiler should
accept use of those extensions without additional flags.
(Though it seems cool in practice, this may not actually work
in reality. For example, the -98 flag on Hugs can only be changed
by restarting Hugs because the authors of the flag doubt that it
would work if you changed the flag between modules because of a
combination of implementation issues and semantic issues.)
2) Portability
GHC, Hugs and NHC require different sets of flags to enable non-H98
extensions so the GHC flags that enable use of rank 2 polymorphism
(say) are different from those used with Hugs.
The obvious fix would be to standardise the set of flags used by
each compiler. Two obstacles:
1) Hugs historic use of single-letter flags.
(This could actually work to our advantage - multi-letter flags
have never been used.)
2) Different compilers may carve up the extension space in different
ways. Most notably, NHC doesn't have all the typesystem extensions
of Hugs/GHC.
Another approach which may (???) be better would be to name each
of the extensions (TREX, PreemptiveConcurrency, CooperativeConcurrency,
ImplicitParameters, ...) and then list which ones are required by each
package. It would be up to the package manager for each compiler to
translate that set of flags into concrete flags for passing to the
compiler. This approach is a bit like using autoconf-style feature
tests.
3) Some flags defy efforts at portability - even between versions.
For example, I very much doubt that the heapsize flags I used with
GHC 0.16 on an Alpha are appropriate for use with GHC 5.x on an x86
never mind their relevance for Hugs.
Not a lot can be done about this - go ahead and provide
"Extra_{GHC,Hugs,NHC,HBC}_Flags" (or whatever it was called).
--
Alastair Reid [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
