"ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction

Compare

rwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
Prelude> let a = (+)
Prelude> :t a
a :: Num a => a -> a -> a

with

rwbarton@morphism:/tmp$ ghci-7.10.1 
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
Prelude> :set -XMonomorphismRestriction
Prelude> let a = (+)
Prelude> :t a
a :: Integer -> Integer -> Integer

Confusing!

This also occurred in 7.8.

Trac metadata

Trac field	Value
Version	7.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added GHCi Tbug Trac import newcomer labels

ghci -XNoExtendedDefaultRules does't turn off ExtendedDefaultRules either:

Prelude> :showi language
base language is: Haskell2010
with the following modifiers:
  -XNoDatatypeContexts
  -XExtendedDefaultRules
  -XNoMonomorphismRestriction
  -XNondecreasingIndentation

This seems to be by design. From #3217 (closed)##10857 (closed):

The DynFlags used to compile code will be computed as follows.

1. ..

When compiling an expression typed on the GHCi command line:

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

I agree it is confusing.

Trac metadata

Trac field	Value
Related	- → #3202 (closed), #3217 (closed)

That is confusing!

What about putting (4) immediately after (1), so that it can be modified by command line or :set commands?

assigned to @cocreature

Hey, I looked into this and it turns out it's actually not that easy to move it to an earlier point because those options should be in the interactive DynFlags which we set only after we have overwritten the DynFlags using the command line arguments.

Now there is an easy solution which consists of just putting it in the standard DynFlags instead of the interactive ones. In fact we already do this for another flag. This works just fine but obviously some tests fail now since it is now not limited to the interactive flags.

The other option is to set all of the interactive DynFlags earlier, but it looks like we then need to have two different set of flags, modify both of them by the command line arguments and then set them. This does not seem like a very nice solution either.

If you are okay with putting it not in the interactive dynflags, then that's definitely the easiest solution, but as I am not really happy with that myself I'll think about it a bit more and try to come up with a less hacky solution.

Which tests fail if you add -XNoMonomorphismRestriction to the standard DynFlags?

You linked to -fimplicit-import-qualified being added to the standard DynFlags. I see there is a TODO (XXX) there, so it looks like this is considered to be a bug. But I'm having trouble coming with an example that would trigger the bug, can you? I tried the following, expecting it to be erroneously accepted by GHCi (when running ghci Test.hs), but it isn't:

Test.hs:

main = print $ Data.List.foldl' (+) 0 [1,2,3]

This fails with error: Not in scope: ‘Data.List.foldl'’. So now I don't understand the difference between the standard DynFlags and the interactive DynFlags.

The tests that fail are

make TEST="dynbrk002 break021 break012 print012 break020 ghci057 T9293 ghci024 ghci058"

and here's the output. One reason for the failure is that :show language shows the extensions whereas atm only :showi language shows them. The other failures seem to be related to the ghci debugger printing some type signatures differently which is probably related to -XExtendedDefaultRules and -XNoMonomorphismRestriction now appearing outside of the interactive session flags as well. Apart from the debugger case I feel like it's mostly a semantic distinction.

Your code doesn't fail because the hack only adds -fimplicit-import-qualified to the DynFlags if load mode is DoInteractive or DoEval. I haven't managed to come up with anything that triggers the bug.

+[1 of 1] Compiling Ghci058          ( Ghci058.hs, interpreted ) [flags changed]
 Ok, modules loaded: Ghci058.

That's unacceptable I think. After compiling a module with -dynamic, and then loading it in GHCi, GHCi shouldn't have to reinterpret it.

Replying to [ticket:10857#comment:107478 cocreature]:

Your code doesn't fail because the hack only adds -fimplicit-import-qualified to the DynFlags if load mode is DoInteractive or DoEval.

But when I run ghci, isn't the load mode always DoInteractive? So shouldn't -fimplicit-import-qualified also apply to modules loaded into GHCi, as in my example? I guess it doesn't, but I don't understand why not.

I can't come up with a nice solution to this, I'll leave it to someone else.

mentioned in issue #10991 (closed)

This might be tricky, and not much fun. Removing newcomers keyword.

mentioned in issue #14551 (closed)

changed milestone to %8.8.1

assigned to @RolandSenn and unassigned @cocreature

Trac metadata

Trac field	Value
Test case	- → make test TESTS="T10857a T10857b"
Differential revisions	- → D5444
Related	#3202 (closed), #3217 (closed) → #3202 (closed), #3217 (closed), #14551 (closed)

Moved patch from Phabricator to Gitlab.

Trac metadata

Trac field	Value
Differential revisions	D5444 →

mentioned in commit f78048f6

Fixed in #10857 (closed).

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Pnormal label