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

[GHC]

#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 simonmar):

 Replying to [comment:9 claus]:
 > > Can you precisely define "compatibility"?  Can you imagine
 implementing (or even describing) it in a simple way?
 >
 > Sure - the same way it is defined currently, in a single file!-)
 Actually, defining and implementing this would be good in any case, as
 there currently are a few oddities..:
 >
 >  - no multiple `default` permitted (as in a single file; this could be
 relaxed to permitting *identical* `default`s)
 >
 >  - no `{-# LANGUAGE X, NoX #-}` (actually, that is currently permitted,
 but I consider it an oversight/bug..)
 >
 >  - no `{-# OPTIONS_GHC -fthis, -fno-this #-}` (again, that is currently
 permitted..)
 >
 > If there are any non-obvious cases, simply require that all modules must
 have the same, identical options for those. In general, proceed as if all
 `*`-ed modules were in a single file, with allowances for identical
 duplicates.
 >
 > My intention here is that explicit settings have priority over implicit
 ones (if one module doesn't have an explicit `default`, another does, then
 the combination has the explicitly given `default`). This merging of
 explicit settings might lead to a module not being loadable with the
 merged settings, but this isn't different from that module depending on
 specific settings, which should be made explicit.
 >
 > An alternative would be to require identical settings in all modules to
 be loaded in a `*` combination. This would be easier to check, but almost
 as cumbersome as permitting only a single `*`-ed module.

 I think you've illustrated my point quite clearly!  There's no sensible
 way to do this that both (a) is obviously the right thing, and (b) doesn't
 require writing a ton of tedious and error-prone comparison code to
 implement.

 > > If this is really a necessary feature, can you describe a compelling
 use case?  One that doesn't have an easy workaround?
 >
 > As I mentioned, a single `*`-ed module would seem to work for me. It is
 just that I've often been annoyed if people who couldn't imagine a use
 case decided that there were no use cases, so I didn't want to fall into
 the same trap. I don't know how many folks still read ghc-bugs, or the
 trac RSS feeds, so perhaps raise the issue on ghc-users, and point to this
 ticket?

 It's more a matter of taste.  A feature is much more likely to be
 implemented if

  * it is obviously the right design.  A proxy we often use for this is
 "can be described simply in the documentation".  The best UI designs
 require zero documentation.
  * it doesn't stretch the internal architecture, e.g. by adding new global
 invariants
  * it has a high effort-to-benefit ratio (subjective of course, and not so
 applicable if someone else does the coding; hint :-)

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