type signatures in export lists

Isaac Dupree isaacdupree at charter.net
Mon Jun 18 07:17:51 EDT 2007

Hash: SHA1

They're not implemented, but they won't be until we decide exactly what
they mean - it's not simple.

(at least the syntax is obvious:

One big question: can their presence have any effect?
* on the module doing the exporting (conflict with the presence of
in-module type-signature for the same thing; type restriction in-module;
monomorphism-restriction-lifting or defaulting-removal of the named thing)
* on modules importing this one (can a module re-export something,
giving it a more restrictive type-signature?)

Case study 1:

module Foo1 (Foo(..), foo :: Foo) where

data Foo = CFoo

foo :: Foo
foo = CFoo

If we interpret it as an in-module type signature, it will be a problem
because there already is one for foo. (unless we should relax the rules
for uniqueness of type signatures anyway?)

Case study 2:

module Foo2 (foo :: Foo) where

data Foo = CFoo

foo :: Foo
foo = CFoo

The type doesn't need to be exported. (which is more likely if it's just
a type synonym than a new type.)  So what scope are the names in the
export-list-type-signature drawn from?  It would be odd if a type
signature couldn't be given because some names weren't exported; but it
would be odd if a module-user looking at the interface saw some types
that weren't defined anywhere visible.

This suggests that wildcards in type signatures could be helpful for this:
module Foo3 (foo :: Int -> Foo -> Bool)
module Foo4 (foo :: Int -> _ -> Bool)

Open for discussion.


Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Haskell-prime mailing list