#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):
> 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.
> 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?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3217#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
