Standardizing the flags that enable non-standard language
extensions seems to me as going too far. There's really no
substitute for standardizing the language if we want to achieve
portability. However, I also know that this can be a painful
process...
So maybe we could agree on turning on a few mature extensions by
default instead, now that they have found their way into general
libraries anyway. Multi-parameter type classes and local
quantification comes to my mind here. But I don't know what
started this discussion, so perhaps the concern is more about
features that don't fit into the world of "semi-standard"
Haskell.
-- Johan
On Monday, June 18, 2001, at 10:13 AM, Alastair David Reid wrote:
>
> [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
