Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#2213 closed bug (fixed)

Confusing flags for rewrite rules

Reported by: dons Owned by: dons
Priority: normal Milestone: 6.10 branch
Component: Compiler Version: 6.8.2
Keywords: rules, warnings Cc: claus, pho@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Functions exported via rewrite rules are incorrectly flagged as "defined but not used" when
-Wall is enabled:

module M ({- rules -}) where

eq :: Eq a => a -> a -> Bool
eq = (==)

{-# RULES
    "rule 1" forall x. x == y = y `eq` x
  #-}

Will emit a bogus:

  M.hs:4:0: Warning: Defined but not used: `eq'

Change History (8)

comment:1 Changed 7 years ago by dons

  • Owner set to dons
  • Status changed from new to assigned

Ah, worked this one out.

-fglasgow-exts is needed to enable rules, otherwise they're considered comments. (Hence the type error in this rule is silently ignored).

Note however, strangely, -frewrite-rules *doesn't* fix this.

comment:2 Changed 7 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 6.10 branch

This is currently rather odd. You need one of ScopedTypeVariables, PolymorphicComponents, ExistentialQuantification, Rank2Types and RankNTypes enabled, as these all turn on lexing of forall. Really, there ought to be a flag for rewrite rules instead (which also turns on lexing of forall).

comment:3 Changed 7 years ago by simonpj

  • Summary changed from -Wall incorrectly warns "Defined but not used" for functions exported via RULES to Confusing flags for rewrite rules

I agree this is totally weird, and we must fix it for 6.10. The current situation is:

  • RULES pragmas are discarded by the lexer unless explicitForallEnabled is on
  • explicitForAllEnabled is set only by the flags Ian mentions above
  • Those flags are set by -fglasgow-exts

There is an optimisation flag -frewrite-rules, which controls whether rewrite rules are applied during optimisation. It's not meant to be a language-extension flag.

We could have a language-extension flag -XRewriteRules, which switches on RULES in source code. (Even without it, optimisation could still use imported rules, as controlled by the optimisation flag -frewrite-rules.) It could be switched on by -fglasgow-exts. It would switch on lexing of forall.

Presumably RULES should be ignored without -XRewriteRules. (Would we want a warning? And yet another warning-supression flag?) I'm a bit concerned that this would break old programs that don't use -fglasgow-exts, but do have -XScopedTypeVariables (say), by silently discarding their rewrite rules. This seems like a strong argument for adding a warning for discarded RULES. This warning would also have warned Don in the program that started this ticket.

Should the optimisation flag still be called -frewrite-rules. I think we should re-title it -frun-rewrite-rules (implied by -O of course).

Nothing very hard here, but better to get the design right first. Comments?

Meanwhile I'll re-title the ticket.

comment:4 Changed 7 years ago by claus

  • Cc claus added; rules warnings removed
  • Keywords rules warnings added

i ran into -frewrite-rules here:

http://www.haskell.org/pipermail/glasgow-haskell-users/2008-June/014912.html

the (slightly incorrectly) observed behaviour is *very* confusing:

  • -frewrite-rules on its own is not sufficient to enable RULES, presumably because they are discarded before they could be enabled
  • -fglasgow-exts on its own is sufficient, presumably because -O implied -frewrite-rules anyway

imho, wanting RULES to be applied implies wanting them to be parsed, not discarded, so -frewrite-rules should imply all relevant language flags. until that is the case, the odd dependency should be documented in the flag reference.

btw, i changed the odd cc, moving rules, warnings to keywords. or do these exist as ccs?

comment:5 Changed 7 years ago by PHO

  • Cc pho@… added

comment:6 Changed 7 years ago by simonpj

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

See the discussion and fix in #2497.

Simon

comment:7 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:8 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple
Note: See TracTickets for help on using tickets.