On Mon, Mar 8, 2010 at 3:36 PM, wren ng thornton wrote:

Gwern Branwen wrote:

...

See http://hackage.haskell.org/trac/hackage/ticket/640

It seems to me that a warning on using the 'haskell98' package wouldn't be a bad thing; those modules have since been split apart in better modules, the names are ever more unfamiliar, etc.

But Duncan thinks it merits discussion.

I'm all for the warnings. And regarding guest's comments, doesn't the Haskell 2010 standard[1] count as an "actual language standard"? If not, then what is it and why isn't it one?

[1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html

Correct me if I'm wrong, but I thought 'HierarchicalModules' was an extension which codifies the 'Foo.Bar' import syntax (as opposed to 'import FooBar'), and didn't address allocation of functions to modules or naming issues like 'Char' vs 'Data.Char' or splitting 'Foreign' up or whatever. -- gwern

Gwern Branwen wrote:

wren ng thornton wrote:

...

I'm all for the warnings. And regarding guest's comments, doesn't the Haskell 2010 standard[1] count as an "actual language standard"? If not, then what is it and why isn't it one?

[1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html

Correct me if I'm wrong, but I thought 'HierarchicalModules' was an extension which codifies the 'Foo.Bar' import syntax (as opposed to 'import FooBar'), and didn't address allocation of functions to modules or naming issues like 'Char' vs 'Data.Char' or splitting 'Foreign' up or whatever.

AFAIK, yes, the HierarchicalModules approval is just allowing dots in module names, rather than discussing what goes where. I was bringing haskell2010 up more to point out that the haskell98 standard is, officially, not up to date. Perhaps we should poke the haskell-prime committee to move the official location of standard functions for the haskell2011 standard? -- Live well, ~wren

Neil Mitchell schrieb:

Hi,

In discussion with Gwern I've raised a bug in HLint to make using Haskell 98 modules a warning. It's not the same as a formal deprecation of those modules, but it's a step in that direction. I think deprecating haskell98 modules is a reasonable step to do at some point in the future, but I don't think that point has arrived yet (we should at least publish Haskell 2010 first).

Maybe Cabal (or HLint) could at least warn about mixed use of haskell98 and base modules, but this would be certainly a hack in Cabal.

Henning Thielemann wrote:

Actually, when using GHCi I like to have the short Haskell98 module names.

I agree that the warning is less important in GHCi during the deprecation stage. However, for consistency, I think the Haskell98 names should go away by default in GHCi when they go away in GHC. You can always enable them manually if they are important to you. Or use dot-ghci and/or :def commands to save keystrokes when setting up your favorite GHCi environments. That is probably a better idea anyway. Regards, Yitz

On 09/03/2010 12:11, Malcolm Wallace wrote:

...

And regarding guest's comments, doesn't the Haskell 2010 standard[1] count as an "actual language standard"? If not, then what is it and why isn't it one?

Haskell 2010 has been decided, but the Language Report itself has not yet been published. So yes, it is a standard, but not one you can refer to (yet).

IIRC, H'2010 makes no changes to the Libraries section of the Report. There was a proposal for 2010 to update the names of the libraries, to their new hierarchical forms. It was not accepted. Thus, the Haskell'98 names are still part of the official 2010 language standard, if I am not mistaken.

The discussion didn't result in a concrete proposal, but there was general agreement that we should remove Directory System Time Locale CPUTime Random and update the others to use hierarchical names: 1. Ratio keep as Data.Ratio 2. Complex keep as Data.Complex 3. Numeric keep as Numeric (?) 4. Ix keep as Data.Ix 5. Array keep as Data.Array 6. List keep as Data.List 7. Maybe keep as Data.Maybe 8. Char keep as Data.Char 9. Monad keep as Control.Monad 10. IO keep as System.IO and the FFI libraries would be added as CError -> Foreign.C.Error CForeign -> Foreign.C CString -> Foreign.C.C.String CTypes -> Foreign.C.Types ForeignPtr -> Foreign.ForeignPtr Int -> Data.Int MarshalAlloc -> Foreign.Marshal.Alloc MarshalArray -> Foreign.Marshal.Array MarshalError -> Foreign.Marshal.Error MarshalUtils -> Foreign.Marshal.Utils StablePtr -> Foreign.StablePtr Storable -> Foreign.Storable Word -> Data.Word (this proposal wasn't discussed publicly, unfortunately. I think that was an oversight.) I was actually planning to look at doing this during the H2010 report update. However, updating the libraries in the report to use the hierarchical names actually gives us a slight problem, in that we then have to provide those modules with exactly those interfaces for ever, presumably via some well-known package. The module names overlap with base, so we'd have to do some package reorganisation. Things could get painful really fast. I'm tempted to not do this in H2010, but defer it until we've really thought about how to manage the transition and future updates. I would like to remove the old superseded modules though: Directory, Time, System, Random, Locale, CPUTime. That would be an easy change, and we can provide a haskell2010 package exporting just the remaining modules. Cheers, Simon

I'm all for supporting the haskell98 *language* (aka "portable" haskell code) except wrt non-hierarchical module names. Without hierarchical module names cabal and hackage are unperceivable. In fact, the haskell98 modules are bit-rotten and the corresponding hierarchical modules (like Data.List) are certainly no "bleeding edge APIs", but the de-facto standard. Christian John Meacham schrieb:

Please don't deprecate these modules.

It is actively contributing to bitrot to deprecate a perfectly useful and well defined API. When I write new code that only needs C, I don't use C++ just because C is older. Likewise, when writing Haskell code today that doesn't require anything more than haskell 98, I use haskell 98. Because it is a well defined standard that I know will be supported by future and past compilers. Unlike writing to some current snapshot of what the libraries look like.

Encouraging people to use bleeding edge APIs just contributes to the already dicey problem of writing future and backwards compatible code in Haskell, in fact, writing to haskell 98 is the _only_ option at the moment with any ability to do so.

Haskell 98 should never be deprecated, because it is a stable, well defined standard that useful programs can be written to if someone chooses to do so and wants their code to have a chance of working down the road without having to continually keep changing it to keep up with libraries changes.

John

On Thu, Mar 11, 2010 at 09:59:11AM -0500, Gwern Branwen wrote:

No one is talking about removing haskell98; my bug report is about warning about use of it. You can go on using 'import Monad' if you like - just like you can go on shadowing variables, omitting pattern-matches & type sigs, naming unused variables, and defining unused functions. Just like with haskell98, there are (contrived and otherwise) scenarios where one actually wants to do those things, which is why they aren't *errors*.

Except that writing a program that just uses Haskell 98 is a virtue, not a vice. When you target a standard your program becomes much easier to maintain. As it is now, it is a major pain to write future compatible haskell. For instance, pretty much every ghc compiler release I have had to modify code due to one of the libraries suddenly exporting something it didn't before. Like you say, qualified imports can help with this, but it still doesn't protect against the meaning of functions changing and can be much harder to maintain. It doesn't matter whether that is unlikely or not, it is sometimes important to _know_ a program or library will continue to work in the future. If you are printing a book with Haskell code, or heck, just want to be able to publish it and not have to keep modifying it every time there is a new compiler release. Right now it is almost impossible to be 'done' with a Haskell program. you continually have to churn the dependency list and keep up with changes in ghc, targetting haskell 98 when possible gets rid of those issues completely. As will targetting Haskell 2010, or any other specific release. We should be _encouraging_ writing against standards when possible, not discouraging it. Haskell 98 may be aethetically displeasing in some ways, but that doesn't diminish its usefulness as a standard.

Nor do you address the multiple strikes against haskell98 that I've already adduced: that it encourages people (like you!) to duplicate library code; that it leads to mixture of modern and old module names (I'm not sure that I've yet run into a package which needed only haskell98 and not also 'base'); that it hides the finer-grained dependencies (reverse dependencies were linked; notice that each package that depends on haskell98 may be screwing up the reverse dependency list of process/random/containers/old-locale/...); etc.

One has to duplicate library code if one wants their program to be portable to libraries/versions of ghc that don't have said code in their library. Having newer packages depend on older, portable packages should not be a burden or force the portable packages to be needlessly changed. If this somehow is an issue, that seems like an issue with the package manager that needs to be addressed, not by the brute force approach of dragging everything to haskell-prime kicking and screaming. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

Hello, I agree with John because I don't think that adding warnings about using the haskell98 package achieves anything meaningful. The issue seems to be a matter of taste---some people like it, some don't, and we already have a system that lets us choose if we want to use it or not. It certainly does not seem in the same class of problems as "incomplete patterns in definitions", for example. As far as indirect dependencies are concerned, I agree that it might be nice to have more control over the packages on which we depend (certainly important in the case of GPLd libraries) but that has nothing to do with the haskell98 package. -Iavor PS: By the way, I don't see how hierarchical names are important in any way to Cabal or hackage: I agree that using "." in module names instead of, say, "_" might look a bit nicer (or just more familiar?) but, as features go, this is a pretty small one. On Thu, Mar 11, 2010 at 6:11 PM, John Meacham wrote:

On Thu, Mar 11, 2010 at 09:59:11AM -0500, Gwern Branwen wrote:

...

No one is talking about removing haskell98; my bug report is about warning about use of it. You can go on using 'import Monad' if you like - just like you can go on shadowing variables, omitting pattern-matches & type sigs, naming unused variables, and defining unused functions. Just like with haskell98, there are (contrived and otherwise) scenarios where one actually wants to do those things, which is why they aren't *errors*.

Except that writing a program that just uses Haskell 98 is a virtue, not a vice. When you target a standard your program becomes much easier to maintain. As it is now, it is a major pain to write future compatible haskell. For instance, pretty much every ghc compiler release I have had to modify code due to one of the libraries suddenly exporting something it didn't before. Like you say, qualified imports can help with this, but it still doesn't protect against the meaning of functions changing and can be much harder to maintain. It doesn't matter whether that is unlikely or not, it is sometimes important to _know_ a program or library will continue to work in the future. If you are printing a book with Haskell code, or heck, just want to be able to publish it and not have to keep modifying it every time there is a new compiler release.  Right now it is almost impossible to be 'done' with a Haskell program. you continually have to churn the dependency list and keep up with changes in ghc, targetting haskell 98 when possible gets rid of those issues completely. As will targetting Haskell 2010, or any other specific release. We should be _encouraging_ writing against standards when possible, not discouraging it. Haskell 98 may be aethetically displeasing in some ways, but that doesn't diminish its usefulness as a standard.

...

Nor do you address the multiple strikes against haskell98 that I've already adduced: that it encourages people (like you!) to duplicate library code; that it leads to mixture of modern and old module names (I'm not sure that I've yet run into a package which needed only haskell98 and not also 'base'); that it hides the finer-grained dependencies (reverse dependencies were linked; notice that each package that depends on haskell98 may be screwing up the reverse dependency list of process/random/containers/old-locale/...); etc.

One has to duplicate library code if one wants their program to be portable to libraries/versions of ghc that don't have said code in their library. Having newer packages depend on older, portable packages should not be a burden or force the portable packages to be needlessly changed. If this somehow is an issue, that seems like an issue with the package manager that needs to be addressed, not by the brute force approach of dragging everything to haskell-prime kicking and screaming.

       John

-- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Okay. Who likes importing "Data.List" and "Monad" in the same module? Anyone? (I'll believe it if you say yes, because I've an inkling of a reason in my head... but you'd better be a real person wanting that, not just a hypothetical.)

I have a distinct preference to use the Haskell'98 module names when I can. Just occasionally, I need a function that was not available in the Haskell'98 libraries. On such occasions, I might tend to copy the definition locally into the application itself, rather than import from base. Even more occasionally, that is not possible, because the function cannot be defined in pure H'98. Examples include unsafeInterleaveIO, unsafeCoerce, etc. That is when I find myself importing e.g. List, Monad, and System.IO.Unsafe next to each other.

if you depend on haskell98, then you depend on: array, base, directory, old-locale, old-time, process, random (which indirectly depend on filepath and time, also.)

As I frequently point out, those dependencies only apply to the ghc compiler. With other compilers, e.g. nhc98, the haskell'98 libraries underlie all the others. Base depends on haskell98, not the other way round. I still believe that ghc made a mistake in turning the dependencies the wrong way. In my opinion, it is one of the main causes of frequent breakage of libraries/apps that depend on base, and of the inability to upgrade base in any given version of ghc. Regards, Malcolm

On 12/03/2010 21:23, Malcolm Wallace wrote:

...

Okay. Who likes importing "Data.List" and "Monad" in the same module? Anyone? (I'll believe it if you say yes, because I've an inkling of a reason in my head... but you'd better be a real person wanting that, not just a hypothetical.)

I have a distinct preference to use the Haskell'98 module names when I can. Just occasionally, I need a function that was not available in the Haskell'98 libraries. On such occasions, I might tend to copy the definition locally into the application itself, rather than import from base. Even more occasionally, that is not possible, because the function cannot be defined in pure H'98. Examples include unsafeInterleaveIO, unsafeCoerce, etc. That is when I find myself importing e.g. List, Monad, and System.IO.Unsafe next to each other.

...

if you depend on haskell98, then you depend on: array, base, directory, old-locale, old-time, process, random (which indirectly depend on filepath and time, also.)

As I frequently point out, those dependencies only apply to the ghc compiler. With other compilers, e.g. nhc98, the haskell'98 libraries underlie all the others. Base depends on haskell98, not the other way round. I still believe that ghc made a mistake in turning the dependencies the wrong way. In my opinion, it is one of the main causes of frequent breakage of libraries/apps that depend on base, and of the inability to upgrade base in any given version of ghc.

Well, I think the right way would be for both packages to depend on an another package, as jhc has done. But I do think that having base depend on haskell98 is definitely the wrong way, since the goal is ultimately to move away from the non-hierarchical names. Having them baked into the root of the dependency tree makes it really hard to get rid of them. That's the reason I went with base<-haskell98: with a view to eventually dropping the non-hierarchical names, and that's the point that originally started the thread, right? Even if we drop the haskell98 dependency from as many packages as we can find, in nhc98 it'll still be lurking right at the root of the tree, whereas in GHC you can be sure it's not polluting your name space or dragging in ancient deprecated libraries (e.g. Time). Cheers, Simon

On Thu, Mar 11, 2010 at 10:00 AM, Yitzchak Gale wrote:

John Meacham wrote:

...

Please don't deprecate these modules. It is actively contributing to bitrot to deprecate a perfectly useful and well defined API.

I think "deprecate" is just the wrong word. Gwern is not saying that we should remove haskell98 from Hackage, nor remove the -98 flag from Hugs, nor build a special case into compilers that make modules not compile if they use Haskell 98 syntax.

As I understand it, the problem he is trying to solve is the following:

Haskell code today uses hierarchical module names almost universally. This has been the case for years. Yet a huge number of packages on Hackage directly or indirectly depend on the the haskell98 module, whose sole purpose is to allow the old non-hierarchical module names from pre-addendum Haskell 98.

Gwern is just trying to think of a way to remove all of those spurious dependencies. I agree that this cleanup would be a good idea. The only question is, how do we best go about it?

Or have I misunderstood?

Thanks, Yitz

Seems reasonable. Besides asking for a warning in Cabal (the logical place, since GHC is too low-level and doesn't handle module/package-level stuff), Neil has already mentioned that hlint will warn about haskell98 module names, and I have been sending in patches removing haskell98 deps - the fewer users of haskell98 there are, the less the cost of adding such a warning. With a three-pronged approach, the pain should be as minimal as possible. -- gwern

On Fri, Mar 12, 2010 at 5:43 PM, Aaron Denney wrote:

On 2010-03-11, Yitzchak Gale wrote:

...

John Meacham wrote:

...

Please don't deprecate these modules. It is actively contributing to bitrot to deprecate a perfectly useful and well defined API.

I think "deprecate" is just the wrong word. Gwern is not saying that we should remove haskell98 from Hackage, nor remove the -98 flag from Hugs, nor build a special case into compilers that make modules not compile if they use Haskell 98 syntax.

It is precisely the right word -- in the context of computer standards it means discouraging use due to new ways of accomplishing the same thing, while still allowing it.  Doing any of those things you mentioned would not be deprecation, but breaking.

...

As I understand it, the problem he is trying to solve is the following:

I don't see why it's a problem, frankly.

...

Haskell code today uses hierarchical module names almost universally. This has been the case for years.

Check and check.

...

Yet a huge number of packages on Hackage directly or indirectly depend on the the haskell98 module, whose sole purpose is to allow the old non-hierarchical module names from pre-addendum Haskell 98.

In other words, to _implement the standard_.  Some people do code to the standard as much as practicable, because that portion is then guaranteed to work, leaving only uncertainties about the portions that aren't Haskell 98.  If you want to instead throw their code on a treadmill of evolving "what works as of GHC-HEAD", then you have to be the maintainer.

...

Gwern is just trying to think of a way to remove all of those spurious dependencies. I agree that this cleanup would be a good idea. The only question is, how do we best go about it?

I don't see how it's a _useful_ cleanup, or that the dependencies are truly spurious.

You haven't been paying attention then, or you're using a different definition of 'spurious' than I am. *Many* packages do not use haskell98! I'm pretty sure I've said this already. I have sent in multiple patches which consisted solely of one line removing haskell98 from the .cabal because the haskell98 modules *were not imported*. I don't know how a dependency can be more spurious than that. -- gwern

On Sat, Mar 13, 2010 at 11:06 AM, Ian Lynagh wrote:

On Fri, Mar 12, 2010 at 08:44:46PM -0500, Gwern Branwen wrote:

...

multiple patches which consisted solely of one line removing haskell98 from the .cabal because the haskell98 modules *were not imported*.

A general "Nothing from dependency is imported" warning would be great, but trickier to implement. It's a similar problem to implementing an "extension isn't used" warning.

Thanks Ian

I've opened a ticket for this: http://hackage.haskell.org/trac/hackage/ticket/643 It's independent of the general issue though. -- gwern

On 03/14/10 22:11, Brandon S. Allbery KF8NH wrote:

On Mar 14, 2010, at 17:55 , Gwern Branwen wrote:

...

On Sat, Mar 13, 2010 at 11:06 AM, Ian Lynagh wrote:

...

On Fri, Mar 12, 2010 at 08:44:46PM -0500, Gwern Branwen wrote:

...

multiple patches which consisted solely of one line removing haskell98 from the .cabal because the haskell98 modules *were not imported*.

A general "Nothing from dependency is imported" warning would be great, but trickier to implement. It's a similar problem to implementing an "extension isn't used" warning.

I've opened a ticket for this: http://hackage.haskell.org/trac/hackage/ticket/643

Actually, doesn't the instances-are-global thing make this essentially impossible without whole-program analysis?

GHC will not find an instance that's never imported, I believe. Therefore dependencies that are nowhere imported can always be safely removed. Is this right? -Isaac

On Mon, Mar 15, 2010 at 3:19 AM, Isaac Dupree wrote:

On 03/14/10 22:11, Brandon S. Allbery KF8NH wrote:

...

On Mar 14, 2010, at 17:55 , Gwern Branwen wrote:

...

On Sat, Mar 13, 2010 at 11:06 AM, Ian Lynagh wrote:

...

On Fri, Mar 12, 2010 at 08:44:46PM -0500, Gwern Branwen wrote:

...

multiple patches which consisted solely of one line removing haskell98 from the .cabal because the haskell98 modules *were not imported*.

A general "Nothing from dependency is imported" warning would be great, but trickier to implement. It's a similar problem to implementing an "extension isn't used" warning.

I've opened a ticket for this: http://hackage.haskell.org/trac/hackage/ticket/643

Actually, doesn't the instances-are-global thing make this essentially impossible without whole-program analysis?

GHC will not find an instance that's never imported, I believe. Therefore dependencies that are nowhere imported can always be safely removed.  Is this right?

No, there are packages that instead of exporting modules, export C header files like bindings-DSL for example: http://hackage.haskell.org/package/bindings-DSL Removing such a dependency will break your build if you #include these header files. However, maybe bindings-DSL is the only example of this type of package. regards, Bas