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