Opened 9 years ago

Last modified 8 years ago

#1921 new feature request

change default to support extensions that involve a change of syntax

Reported by: alex Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.8.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Use of a lot of extensions is obvious from the non-haskell-98 syntax they require.

GHC should default to supporting these extenions with a flag to tell the use what extensions are in use.

GHC should require that extensions that change the meaning of an already valid haskell-98 file should appear in pragmas in the source file.

More radical: GHC should not allow extenions flags on the command line.

Change History (6)

comment:1 Changed 9 years ago by alex

the reason for not allowing extension flags on the command line is that source files should have all the information necessary to interpret them.

comment:2 Changed 9 years ago by duncan

difficulty: Unknown

Not very radical: GHC's warning messages that suggest using a language extensions should suggest using a LANGUAGE pragma in the source rather than an -X extension flag on the command line.

comment:3 Changed 9 years ago by claus

defaults are always going to rub some users the wrong way. why not make it easier to specify what you want? i agree with the goal that a source file should have all the information needed to interpret it, so lets start with that:

  • currently, the default is haskell98, but there is no way to specify that a source should be haskell98, which is bad if haskell' ever succeeds.
  • there is no way to specify that a source should be haskell', which matches the general silence from that direction, but needs to be remedied at some point.
  • it used to be that glasgow-exts switched on all ghc extensions, which is bad because nobody knows what they are, for any given source file (ghc version dependent). it now switches on "most" ghc extensions, whatever that may mean for any particular version.
  • the recent trend is to have a flag for every single feature, which is less descriptive or portable than it might sound (cabal simply copies ghc extension names, hugs has different interpretations of shared extensions, such as overlapping instances combined with functional dependencies). it is also a real pain without support for abstraction.

i think it would also be useful to distinguish between sources in development and release versions: the former want flexibility, the latter want preciseness. and i certainly do not want to repeat all those language flags from the sources for each ghci session!-)

a few suggestions:

  • it would be nice to have shortcuts for typical combinations of features, including Haskell98 and Haskell98+FFI+Modules, as well as Haskell'<version>.
  • it would be nice to be able to switch between development and release mode, where the former should enable all recognisable features (unless explicitly disabled), with warnings, while the latter should disable all unspecified features, with errors. the former would give the benefits of the old uses of glasgow-exts, the latter would remove their disadvantages. warnings and errors should be formatted in a way that enables ides/editors to insert the necessary flags in the source.
  • it would be nice to enable project-wide definitions of feature combinations, but that won't benefit single-source projects, and it would need to be easy to find the definitions (project.cabal file? separate project.extensions file?)

comment:4 Changed 9 years ago by igloo

Milestone: _|_

comment:5 Changed 8 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:6 Changed 8 years ago by simonmar

Operating System: UnknownUnknown/Multiple
Note: See TracTickets for help on using tickets.