Export lists in modules
Malcolm.Wallace at cs.york.ac.uk
Wed Feb 22 12:27:01 EST 2006
"Simon Marlow" <simonmar at microsoft.com> wrote:
> You're combining two extensions here - type signatures in export lists
> and tagging exported entities. Not a problem, but I don't think
> they're inextricably linked.
Indeed. I made them separate pages on the wiki. They were combined in
my email only because Simon PJ asked how they related to each other.
Although I now see that was not really his question at all.
> But you don't need to go so far as to indicate
> the difference between type/data/newtype - just differentiating
> classes from tycons is enough to separate the namespaces.
Yes. However it could be slightly confusing that one writes "newtype"
in the module body, but "data" in the module header?
> It's less clear to me whether type and data/newtype
> should be distinguished or not, which is why I asked the question.
They are already distinguished in ghc. It always complains to me when I
in an export list, where the Foo is a type synonym rather than a
datatype. (Not that I necessarily agree with ghc's behaviour here...
:-) You will notice that for this reason, the export production for
"type Foo" does not permit a subordinate list. However, I would be
equally happy to combine type/newtype/data into a single keyword for
> BTW, I think Simon PJ was asking about how to *declare* types &
> classes in export lists, given that you're adding signatures to export
> lists which are a kind of declaration. If you want to put more of the
> interface into the export list, shouldn't you put it all in?
Yes, I see the point. In the fullness of time, perhaps we will indeed
specify the module interface in full, including datatype definitions.
But for the moment, I am more interested in regularising existing
More information about the Haskell-prime