[Hackage] #640: Cabal should warn about haskell98 dependencies
#640: Cabal should warn about haskell98 dependencies ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: check, warn, haskell98 Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- I grepped through my collection of repos, and found dozens upon dozens of uses of the 'haskell98' package (for the full list, see http://community.haskell.org/~gwern/wiki/TODO.page & scroll down). Now, either a package uses the haskell98 module names or it doesn't use them. If the package doesn't actually use any of the old module names, then clearly that's bad and it should be removed and the developer should be warned about this unconditionally. If the package does use the old module names, this is bad too: most every Haskeller got started after the hierarchical modules were made official and general, and the old module names are akin to n+k patterns - they are things that should be removed, because modules using the hierarchical module names are more comprehensible to Haskellers than the old haskell98 modules, which mingle things that have been separated (Foreign comes to mind). So use of haskell98 ought to be warned about here as well. Given that both common situations are bad and ought to be warned about, I think Cabal check ought to emit a warning whenever haskell98 is used. There *may* be some compiler or bootstrapping-related cases where haskell98 is genuinely useful, but I'm doubtful any such exist, and such would be far in the minority anyway. -- gwern -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/640 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#640: Cabal should warn about haskell98 dependencies ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: check, warn, haskell98 Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Comment(by guest): Since Haskell'98 is still de-facto the only actual language standard we have, and the haskell98 package embodies the libraries specified in that standard, I think it would be very presumptious to give a warning. Warnings should be reserved for things that are potentially dangerous, not for users who do the right thing and follow the published standards (unless the latter is actually broken, of course). -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/640#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#640: Cabal should warn about haskell98 dependencies ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: check, warn, haskell98 Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Description changed by guest: Old description:
I grepped through my collection of repos, and found dozens upon dozens of uses of the 'haskell98' package (for the full list, see http://community.haskell.org/~gwern/wiki/TODO.page & scroll down).
Now, either a package uses the haskell98 module names or it doesn't use them. If the package doesn't actually use any of the old module names, then clearly that's bad and it should be removed and the developer should be warned about this unconditionally. If the package does use the old module names, this is bad too: most every Haskeller got started after the hierarchical modules were made official and general, and the old module names are akin to n+k patterns - they are things that should be removed, because modules using the hierarchical module names are more comprehensible to Haskellers than the old haskell98 modules, which mingle things that have been separated (Foreign comes to mind). So use of haskell98 ought to be warned about here as well.
Given that both common situations are bad and ought to be warned about, I think Cabal check ought to emit a warning whenever haskell98 is used.
There *may* be some compiler or bootstrapping-related cases where haskell98 is genuinely useful, but I'm doubtful any such exist, and such would be far in the minority anyway.
-- gwern
New description: GHC warns about non-dangerous things. What's dangerous about redundant imports, or unused variable names? The hierarchical modules are hardly unstable new innovations; Data.List or Control.Monad aren't moving around. More than a decade later, it's time for people to use the module names people expect. -- -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/640#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#640: Cabal should warn about haskell98 dependencies ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: check, warn, haskell98 Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Description changed by guest: Old description:
GHC warns about non-dangerous things. What's dangerous about redundant imports, or unused variable names? The hierarchical modules are hardly unstable new innovations; Data.List or Control.Monad aren't moving around. More than a decade later, it's time for people to use the module names people expect.
New description: I grepped through my collection of repos, and found dozens upon dozens of uses of the 'haskell98' package (for the full list, see http://community.haskell.org/~gwern/wiki/TODO.page & scroll down). Now, either a package uses the haskell98 module names or it doesn't use them. If the package doesn't actually use any of the old module names, then clearly that's bad and it should be removed and the developer should be warned about this unconditionally. If the package does use the old module names, this is bad too: most every Haskeller got started after the hierarchical modules were made official and general, and the old module names are akin to n+k patterns - they are things that should be removed, because modules using the hierarchical module names are more comprehensible to Haskellers than the old haskell98 modules, which mingle things that have been separated (Foreign comes to mind). So use of haskell98 ought to be warned about here as well. Given that both common situations are bad and ought to be warned about, I think Cabal check ought to emit a warning whenever haskell98 is used. There *may* be some compiler or bootstrapping-related cases where haskell98 is genuinely useful, but I'm doubtful any such exist, and such would be far in the minority anyway. -- gwern -- -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/640#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#640: Cabal should warn about haskell98 dependencies ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: check, warn, haskell98 Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Comment(by guest): GHC warns about non-dangerous things. What's dangerous about redundant imports, or unused variable names? The hierarchical modules are hardly unstable new innovations; Data.List or Control.Monad aren't moving around. And further, aren't the new module names an *improvement*? I mean, that's why they were created in the first place, right, because the Haskell '98 choices weren't so good. More than a decade later, it's time for people to use the module names people expect. If people really want to use ancient module names, then that's fine; this is just a warning and not an error. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/640#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#640: Cabal should warn about haskell98 dependencies ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: check, warn, haskell98 Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Comment(by duncan): I suspect this debate should be taken to the libraries list. If there's a concensus there then we can do something about it. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/640#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#640: Cabal should warn about haskell98 dependencies ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: check, warn, haskell98 Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Comment(by guest): Replying to [comment:5 duncan]:
I suspect this debate should be taken to the libraries list. If there's a concensus there then we can do something about it.
Alright. I've done so: http://www.haskell.org/pipermail/libraries/2010-March/013115.html (thread in general: http://www.haskell.org/pipermail/libraries/2010-March/thread.html#13115 ) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/640#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage