Opened 7 years ago

Closed 3 years ago

#1877 closed task (fixed)

Change the meaning of -fextended-default-rules

Reported by: simonmar Owned by:
Priority: lowest Milestone: 7.6.2
Component: GHCi Version: 6.8.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Currently -fextended-default-rules applies to source code modules. GHCi has the extended defaulting behaviour by default for expressions typed at the prompt, and there's no way to change that.

We propose the following change: extended defaulting would only ever apply to expressions typed at the GHCi prompt, and it would be disabled with -fno-extended-default-rules (on by default).

See also #1200, where -fextended-default-rules was introduced.

Change History (18)

comment:1 Changed 7 years ago by simonmar

  • difficulty changed from Unknown to Easy (1 hr)

comment:2 Changed 7 years ago by sorear

Note that this will break lambdabot, which wraps user-provided code in a module and compiles it with -fextended-default-rules and -O2. Some other method will need to be found to access that combination of functionality.

comment:3 follow-up: Changed 7 years ago by igloo

OK, thanks for pointing that out, sorear. It sounds like we need 2 flags then: One to control behaviour for code typed at the GHCi prompt, and one for the behaviour for code from files. In which case we should leave the existing flag with its current meaning and add one to control the behaviour for code typed at the GHCi prompt.

comment:4 in reply to: ↑ 3 Changed 7 years ago by SamB

Replying to igloo:

OK, thanks for pointing that out, sorear. It sounds like we need 2 flags then: One to control behaviour for code typed at the GHCi prompt, and one for the behaviour for code from files. In which case we should leave the existing flag with its current meaning and add one to control the behaviour for code typed at the GHCi prompt.

What about the -X flag? We could use that one for source files and -fextended-default-rules for GHCi.

comment:5 Changed 7 years ago by simonpj

I'm missing something.

  • If you put -fextended-default-rules (or a corresponding -X language flag) in a module, it should apply to that module.
  • If you :set -fno-extended-default-rules at the GHCi prompt, it should switch it off for GHCi.

Ah, hmm, maybe I see. Say you :set -fallow-overlapping-instances at the GHCi prompt. That setting also applies when GHCi compiles a module, doesn't it? If you didn't want overlapping instances in the module there's no way to switch it off, short of putting -fno-allow-overlapping-instances in the module, which seems wrong.

But in the case of extended-defaults, GHCi typically has it on, but we don't want to have it on by default for a module. That's a new situation. An ad-hoc solution would be to splat the flags with -fno-extended-defaults just before GHCi compiles a module.

comment:6 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:7 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:8 Changed 6 years ago by igloo

  • Milestone changed from 6.10 branch to 6.12 branch

comment:9 Changed 5 years ago by simonmar

  • difficulty changed from Easy (1 hr) to Easy (less than 1 hour)

comment:10 Changed 5 years ago by igloo

  • Milestone changed from 6.12 branch to 6.12.3

comment:11 Changed 5 years ago by igloo

  • Milestone changed from 6.12.3 to 6.14.1
  • Priority changed from normal to low

comment:12 Changed 4 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:13 Changed 4 years ago by igloo

  • Milestone changed from 7.0.2 to 7.2.1

comment:14 Changed 3 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1

comment:15 Changed 3 years ago by igloo

  • Milestone changed from 7.4.1 to 7.6.1
  • Priority changed from low to lowest

comment:16 Changed 3 years ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:17 Changed 3 years ago by simonpj

Acutally, isn't this fixed? We now have :set and :seti in GHCi, see the manual 2.8.3. So can we close this ticket?

Simon

comment:18 Changed 3 years ago by simonmar

  • Resolution set to fixed
  • Status changed from new to closed

Yes, I think we can.

Note: See TracTickets for help on using tickets.