[GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions

GHC trac at galois.com
Tue May 12 06:21:06 EDT 2009


#3217: Make GHCi have separate flags for interactive Haskell expressions
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:                  
        Type:  feature request   |       Status:  new             
    Priority:  normal            |    Milestone:  6.12 branch     
   Component:  Compiler          |      Version:  6.10.2          
    Severity:  normal            |   Resolution:                  
    Keywords:                    |   Difficulty:  Unknown         
    Testcase:                    |           Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
---------------------------------+------------------------------------------
Comment (by claus):

 I'm no fan of either MonoMorphismRestriction or GHCi's extended defaulting
 rules (the '()' part, in particular), but I wonder whether adding yet
 another level of settings would really be an improvement.

 It is bad enough that GHCi doesn't easily inherit options/language flags
 from the modules it loads (if I work in a module that has, eg, `LANGUAGE
 QuasiQuotes`, I still need to `:set -XQuasiQuotes` in the GHCi session,
 and so on) - I wouldn't want to have to think about a third level of
 settings. But as long as there is a way for me never to let the various
 levels of settings get out of sync, I don't need to stand in the way of
 people who are really, really sure they want to do this to themselves..

 >Arguably it'd be good to have a command to display the current flag
 settings (of either DynFlags) but that's another blob of work.

 Part of it is there, but it is complicated by the distinction between
 language and other options, as well as the sheer number of options GHC has
 accumulated. `:set` not only shows current *non-language* dynamic flag
 settings, it has a separate group for settings that are particularly
 likely to be relevant for working in GHCi. And `:show languages` shows
 currently active language flags.
 {{{
 Prelude> :set
 options currently set: none.
 GHCi-specific dynamic flag settings:
   -fno-print-explicit-foralls
   -fno-print-bind-result
   -fno-break-on-exception
   -fno-break-on-error
   -fno-print-evld-with-show
 other dynamic, non-language, flag settings:
   -fwarn-dodgy-foreign-imports
   -fno-warn-dodgy-imports
   -fwarn-duplicate-exports
   -fno-warn-hi-shadowing
   ...
 }}}
 {{{
 Prelude> :show languages
 active language flags:
   -XImplicitPrelude
   -XMonomorphismRestriction
   -XMonoPatBinds
 }}}
 I'm not exactly sure why this latter list is as it is (it was decided to
 show only non-default language flags there, but I've certainly not set
 `MonomorphismRestriction` explicitly)? Perhaps `:show languages` should be
 changed to show all language flag settings, with a separate group for non-
 default settings (or perhaps just listing for each entry whether or not it
 has the default setting, and use the separate group to highlight GHCi-
 specific flags instead, similar to `:set`)?

 But if users are not aware of the current settings, or the ways to
 display/change them, are they really going to be aware of another level of
 settings that influences what is going on? Could raising awareness of
 current possibilities achieve the same goal with less confusion? Talking
 about confusion, I had thought the '()' part of `ExtendedDefaultRules` was
 GHCi-only (or is this distinction part of what you are aiming for with
 this ticket?)..

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3217#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the Glasgow-haskell-bugs mailing list