Breaking Haskell 98 compatibility would be extremely naughty ;-)
Multi-parameter type classes haven't been adopted by all the compilers
yet, and the NHC guys tend to get (understandably) annoyed when folk use
non-standard features in library code, so keeping a flag for these
features is the least we can do. Arguably there ought to be some other
indication in the source code of what non-standard features a module
requires - the closest we come to this at the moment is that GHC allows
you to say
{-# OPTIONS -fglasgow-exts #-}
to enable GHC extensions in the source.
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.
Cheers,
Simon
> -----Original Message-----
> From: Johan Nordlander [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 7:44 PM
> To: Alastair David Reid
> Cc: Simon Marlow; S.D.Mechveliani; [EMAIL PROTECTED]
> Subject: Re: ghc_extra_opts in package
>
>
> 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
