type signatures in export lists

[Arie Peterson]

Isaac Dupree wrote:

> 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?)

Letting an export-list type signature be equivalent to a normal one has
the benefit of being simple (to explain and implement). Exporting a
function with a less polymorphic type than its in-module type seems a bit
awkward: you would have two different functions (one internal and one
exported) with the same name.

If export-list and normal type signatures would be equivalent, the only
benefit of allowing the former (compared to writing it in a comment) would
be that the compiler can check it for consistency. Right?

> 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.

As a user of the module, I would argue that all types (including synonyms)
appearing in the signature of an exported function should be exported as
well. Not sure if this needs to be enforced, though.


Regards,

Arie