new extension in jhc: explicit namespaces in import/export lists

Hi, I implemented an extension in jhc that I thought the community might have feedback on and feel that a variant of it would be a candidate for future standardization. Here is the section from the jhc manual describing it. The 'kind' information is specific to jhc, and with this extension I'd really like to get rid of the wart in haskell 98 that names in 'hiding' lists are treated differently than names otherwise. I will likely make that change in jhc in the future once I work out the details of the best way to be backwards compatible. I have seen this exact proposal more-or-less come up on the lists periodically, so I guess I am just pointing to a concrete implementation now. # Explicit namespaces in import/export lists jhc allows explicit namespaces in import export lists. In haskell 98, a name such as 'Foo' in an export list will indicate that all of a class named Foo, a type named 'Foo' and a data constructor named 'Foo' shoud be exported. Jhc allows finer grained control by prefixing exports with a namespace indicator. The valid namespace indicators are * 'type' - The name is a type, as in something defined by type , newtype , or data , or the constructors of a kind declaration. * 'class' - Specifies that the name is that of a class. * 'data' - Specifies that the name is a data constructor. * 'kind' - specifies that the name is a user defined kind. In addition, classes and types are in independent namespaces, so a type and a class of the same name may be in scope and not conflict. When an unqualified name is given in a import/export list then all names that match it that are in scope are matched. The only exception is a holdover from haskell 98 where in hiding lists data constructors are not matched. This behavior may change in the future when explicit namespaces are used, so it should not be relied upon when using explicit namespaces. John

* John Meacham
In haskell 98 [...]
Not sure what you mean here. You aren't going to modify an existing standard, are you? :)
[...] a name such as 'Foo' in an export list will indicate that all of a class named Foo, a type named 'Foo' and a data constructor named 'Foo' shoud be exported.
This bit doesn't sound right... I think this behaviour would be something that people will more often fight against (by using namespaces) than appreciate. (Esp. that Foo exports both the type and the data constructor.) How about this: Foo in the export list may refer to a class, a type or a kind (but not a data constructor). It is an error if multiple entities with the name Foo are in scope. I see your point regarding 'hiding' inconsistency, but I'd prefer having 'hiding' fixed (in a similar way). -- Roman I. Cheplyaka :: http://ro-che.info/

On Sun, Feb 12, 2012 at 11:26 PM, Roman Cheplyaka
* John Meacham
[2012-02-12 19:26:24-0800] In haskell 98 [...]
Not sure what you mean here. You aren't going to modify an existing standard, are you? :)
[...] a name such as 'Foo' in an export list will indicate that all of a class named Foo, a type named 'Foo' and a data constructor named 'Foo' shoud be exported.
This bit doesn't sound right... I think this behaviour would be something that people will more often fight against (by using namespaces) than appreciate. (Esp. that Foo exports both the type and the data constructor.)
Yeah, I worded it incorrectly, actually it is more that I read my own code incorrectly :) The data constructor isn't matched. as stands my extension behaves identically to h2010 rules when no namespace specifiers are used. When a namespace specifier is used, the declaration is restricted to just the names that match that namespace. So it is transparent when not used.
How about this:
Foo in the export list may refer to a class, a type or a kind (but not a data constructor). It is an error if multiple entities with the name Foo are in scope.
Allowing multiple things of the same name was part of the goal, in that you can use the explicit namespaces to restrict it if it is what you intend.. But I suppose that could be considered an independent change. In any case, part of the reason for implementing this in jhc was to experiment with variants like this too see what works. Actually, perhaps a better rule would be "it is an error if multiple entities within the same namespace are matched" hmm.. not sure on that one yet...
I see your point regarding 'hiding' inconsistency, but I'd prefer having 'hiding' fixed (in a similar way).
Yeah, it is just annoying that there is this one exception. John
participants (2)
-
John Meacham
-
Roman Cheplyaka