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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

John Meacham
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

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [jhc] new extension in jhc: explicit namespaces in import/export lists

Roman Cheplyaka-2
* John Meacham <[hidden email]> [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.)

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/

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: [jhc] new extension in jhc: explicit namespaces in import/export lists

John Meacham
On Sun, Feb 12, 2012 at 11:26 PM, Roman Cheplyaka <[hidden email]> wrote:

> * John Meacham <[hidden email]> [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

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime