[GHC] #3217: Make GHCi have separate flags for interactive
Haskell expressions
GHC
trac at galois.com
Wed May 13 13:17:20 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):
> > (eg., I'd be tempted to classify `:m +*Data.Map +*Data.IntMap` as an
error, even if the source are available, on the rationale that `:m +mod`
means `import` while `:m +*mod` means `include`).
>
> I'd be tempted to agree, although this is a fairly deep change. The
context is currently `([Module],[Module])`, this would mean changing it to
`Either Module [Module]`, or perhaps `([Module], Maybe Module)`.
I probably misunderstand your intentions there, but `([Module],[Module])`
should be fine (assuming that this lists `*`-ed and other modules
separately), as long as only modules with compatible pragmas, defaults,
and bindings can be added to the `*`-ed modules list. The
`*Data.Map`/`*Data.IntMap` example would fail only because both define the
same names (which is possible in `import`/`:m +mod`, but not in
`include`/`:m +*mod`).
> If we made this change, then I think it makes sense to take into account
the flags and defaults of the "current" module.
Thanks. I think I could live with only one `*`-ed module, if that was
necessary to get this consistency, but there's no telling what wonderful
uses other GHCi users have come up with, or what their preferences are..
So permitting multiple `*`-ed modules sounds safer - just adding the
requirement that they have to be compatible.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3217#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list