Please don't deprecate Haskell 98 modules.

John Meacham john at
Fri Mar 12 16:41:52 EST 2010

On Fri, Mar 12, 2010 at 09:23:46PM +0000, Malcolm Wallace wrote:
>> 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.

jhc actually has another system, where base and haskell98 both depend on
'jhc' which underlys everything. Or, that is the goal at least, I
originally copied ghc's design for 'base' but have been moving away to
something more logical given jhc's somewhat different library
implementation. The transition isn't complete though.

The general idea for compatibility with other compilers (including other
versions of jhc) is to use the ability for jhc libraries to re-export
modules under different names. for instance, haskell98 will probably do
something like 

export Compat.Haskell98.Prelude as Prelude
export Compat.Haskell98.List as List

and haskell98 will be more of an 'interface specification' than a
packaget itself. likewise I could have something like ghc-base4 (to give
compatability with ghc's base-4.x that does as

export Compat.Haskell98.Prelude as Prelude
export Compat.Base4.Data.List as Data.List

now, module names are resolved lazily (like function names in haskell
code) so the fact that ghc-base4 and haskell98 both export Prelude
doesn't hurt, since they both export the same underlying Prelude there
is no conflict, this is in contrast to creating a dummy module that just
re-exports an entire other module as we currently see in ghc's haskell98
package. A different module in the same program can even use
'haskell2020' and they will still link together, each module using the
appropriate imports for which it was written.


John Meacham - ⑆⑆john⑈ -

More information about the Libraries mailing list