[Haskell-cafe] Re: [Haskell] ANNOUNCE: Haskell 2010 Report (final)

[Simon Marlow]

On 12/07/2010 22:12, John Meacham wrote:
> On Mon, Jul 12, 2010 at 01:50:01PM +0100, Simon Marlow wrote:
>> Right.  I like the idea of packages being able to declare re-exported
>> modules, indeed I considered doing this in GHC (when we needed base3)
>> but decided not to mainly because we would still need PackageImports,
>> and once you have PackageImports you can implement re-exports using
>> that, albeit with more boilerplate.  The advantage of direct re-exports,
>> as you say, is that it avoids a conflict when the module is imported.
>> However, since some of the modules would conflict anyway, there didn't
>> seem to be much advantage in avoiding the conflict in some cases but not
>> others.
>
> Well, a main useful case is that I can do -phaskell98 and -phaskell2010
> at the same time. So I can make the default jhc behavior be the union of
> the two languages easily.

That works in GHC too: the modules of those two packages don't overlap. 
  That is partly because we never moved Prelude from base to haskell98.

But suppose the Haskell 2010 Prelude had some differences from the 
Haskell 98 Prelude - then a direct re-export wouldn't work, and you'd be 
stuck with conflicts again.  So my main point is that while direct 
re-exports avoid conflicts sometimes, they're not a general solution, 
and eventually you run into the same problems again.  There are 
differences between several Haskell 2010 modules and the equivalent base 
modules, so you won't be able to use re-exports for those.

> There is also some philosophy behind it. I don't like coupling things
> that don't need to be coupled, such as the interface a library exports
> and the place that interface is implemented.

I agree with the philosophy, but I don't understand how package 
re-exports are part of its implementation - the Haskell module system 
already lets you re-export entities and therefore decouple the 
implementation from the API.

>>> I think the ability for a package to define an 'interface' built up from
>>> other re-exported modules will be very useful going forward, I am not
>>> sure how hard something like that would be to implement in ghc, but it
>>> may be worth it in the future.
>>
>> Isn't that what PackageImports lets you do?
>
> Hmm.. maybe. Jhc doesn't have PackageImports, the idea being that you
> re-export modules rather than importing them from a specific package and
> exporting their interface.  So, it sort of shifts the effort from the
 > interface makers to the implementors, as in, the Haskell 98 Prelude
 > will actually have to be in a module called Compat.Haskell98.Prelude
 > and just re-exported by the 'haskell98' and 'haskell2010' modules.

I don't think the difference is as fundamental as you make out.  In 
Haskell you can already write

   module A ( module B ) where
   import B

which is the essence of re-exporting a module, and preserves the 
interface/implementation separation.  Now suppose A and B are the same 
module name, from different packages.  To implement this re-export you 
can either

  (1) Use a package re-export (in JHC)
  (2) Somehow avoid A and B being the same, e.g. by having an
      intermediate like Compat.Haskell98.Prelude
  (3) Use PackageImports (in GHC)

the advantage of (1) is that you can have both packages in scope without 
a conflict, whereas in (2/3) the two modules can export different 
interfaces, while still separating the implementation from the 
interface.  I think of PackageImports as just an optimisation that lets 
you avoid the intermediate module in (2).

So again, my point is that in the general case the APIs diverge, so you 
don't get to do (1), or you only get to do it for some modules, which 
could be confusing for users.

> In one
> sense 'Compat.Haskell98' sort of acts as a package import, but it isn't
> actually tied to a package, it just refers to the
> Compat.Haskell98.Prelude in scope. I also have a large aversion to
> allowing package names to infect source files carte blanche. It blurs
> the line between the language itself and the environment the language
> runs in. It may be neccesarry at some point, but I'll put it off until a
> case comes up that makes it abundantly clear that it is needed.

I agree with your aversion to putting package names in the source code, 
which is why we don't advertise PackageImports as an extension that we 
expect end users to use, and we don't let you use version numbers.

Cheers,
	Simon