Proposal: Slim base-5 API package

Joachim Breitner mail at
Tue Jul 16 23:39:53 CEST 2013


Am Montag, den 15.07.2013, 19:36 +0200 schrieb Bardur Arantsson:
> On 2013-07-15 09:56, Joachim Breitner wrote:
> A question related to this:
> Is it possible for such an "API package" to actually explicitly specify
> type signatures of its re-exports, perhaps using abstract types where no
> particular implementation would be dictated?
> It seems to me that this would be highly valuable to provide a)
> documentation which could be shared across all implementations, b) a
> contract such that a given implementation can tell whether it really is
> conforming to expected type signatures, and c) a contract such that
> *users* of base can be certain that they're not unwittingly relying on
> implementation details in a given implementation of base.

I don’t think so; this would be a very different module system then.

What you can do is this:

#ifdef API
module Foo where
-- | Documentation for Bar
data Bar -- abstract

-- | Documentation for f
f :: Int -> Bar
f = undefined
module Foo (Foo) where
import "impl-package" Foo

so you can compile it with -DAPI to get the specification and the
documentation, and compile it without to get the real thing, and then
have tool support to compare the two(b).
Also, with -DAPI you can get the  shared documentation (a). 
c) can already be achieved now by just exporting the relevant details:
Via base, you only can import the Foo type abstractly; if you want to
get access to its constructors, you have to import base-impl.

> Without such checks I fear that things may end up in a bit of a mess
> type-wise if there *were* actually to be multiple implementations at
> some point. (Though it would certainly improve on the curren situtation).

I don’t think the plan is to have different implementations of stuff in
base at the same time. If different compilers (fay) replace the
base-implementing packages, then there is another implementation, but
that would never interfere with a definition on GHC. Or what scenario do
you have in mind?

> Overall, the proposal sounds like a great idea to start to get a handle
> on the mess that is base ;).



Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  Jabber: nomeata at  • GPG-Key: 0x4743206C
  Debian Developer: nomeata at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Libraries mailing list