[GHC] #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible

20 Jan 2016

      #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full
top-level scope is visible
-------------------------------------+-------------------------------------
           Reporter:  ezyang         |             Owner:
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  GHCi           |           Version:  7.11
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 While helping a Haskell beginner today, we came across this behavior and I
 wondered why there wasn't already a ticket for this problem in the
 tracker. In fact, this is technically a duplicate of #3217, but that
 ticket is long (and it was difficult to find!) so I just want to file a
 new ticket to summarize what needs to be done.

 The essential problem is that a user is editing a file that looks like
 this:

 {{{
 {-# LANGUAGE OverloadedStrings #-}
 module A where
 ... some code ...
 }}}

 and they load this into ghci with `ghci A.hs`.  They then might reasonably
 type a string into the GHCi prompt and expect it to be overloaded... but
 it will not be! They had to have invoked GHCi with `ghci
 -XOverloadedStrings A.hs`. This behavior is unexpected and not very nice.

 The proposal is this: (from
 https://ghc.haskell.org/trac/ghc/ticket/3217#comment:15)

 GHCi should be changed so that at most one module is "fully open",
 currently denoted *M in GHCi's prompt. If a module M is "fully open",
 expressions typed at the GHCi prompt are interpreted (roughly) as if they
 were written in M itself. Specifically:

 * All the top-level things in the module are in scope
 * The per-module flags in {-# OPTIONS #-} and {-# LANGUAGE #-} pragmas
 * M's default declaration holds

 Note that currently more than one module can be fully open, and their top
 level scopes are merged. We propose to make that at most one.

 When compiling an expression typed on the GHCi command line:
 * Start with the baseline DynFlags
 * Apply flags specified on the original command-line
 * (Perhaps: apply flags specified by :set in this GHCi session. We aren't
 sure whether or not to do this.)
 * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules)
 * Apply flags specified by :seti in this GHCi session
 * If there is a fully-open module M, apply flags specified in M itself.
 That is, flags in M get the last word.

 Implementing this plan will require some representation changes. In
 particular, since we need to apply M's source-code flags in two difference
 places, we really need to remember the diffs with M, perhaps as a
 `(DynFlags -> DynFlags)` function or something.

 See also: https://ghc.haskell.org/trac/ghc/ticket/3217#comment:28

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11469
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

GHC

GHC

GHC

GHC

GHC

GHC

GHC

tags

participants (1)