Please don't deprecate Haskell 98 modules.

Simon Marlow marlowsd at gmail.com
Wed Mar 17 09:35:10 EDT 2010


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


More information about the Libraries mailing list