Packages and modules

[Brian Hulley]

Simon Peyton-Jones wrote:
>> 1) Qualified names:
>>
>>   import A.B.C( T1 ) from "foo"
>>   import A.B.C( T2 ) from "bar"
>>   type S = A.B.C.T1 -> A.B.C.T2
>>
>> I'd suggest that the above should give a compiler error that A.B.C is
>> ambiguous (as a qualifier), rather than allowing T1 to disambiguate
>> it, because otherwise it allows people to write code that could be
>> very hard to understand ie within the code, every occurrence of
>> A.B.C as a qualifier should refer to the same module. (Otherwise the
>> thing qualified qualifies the qualifier that's qualifying it...)
>
> But that's inconsistent with Haskell 98.  In H98 you can say
> import M( T1 ) as Q
> import N( T2 ) as Q
> type S = Q.T1 -> Q.T2
> and it'll work just fine.  You may think it should not work, but
> that's water under the bridge.  We should be consistent here.

But Q is an alias not a concrete module name like A.B.C so this is not quite 
the same thing imho. Q could be regarded as a new local module which 
contains T1 from M and T2 from N, so Q.T1 and Q.T2 both use the "same" Q. 
However to allow A.B.C.T1 and A.B.C.T2 is to assert that A.B.C is somehow 
semantically the "same" entity in both cases even though it is just pure 
happenstance that these modules have the same name in their respective 
packages. Still I can see it may be useful to regard A.B.C now as a kind of 
alias as well and within that view consistency with H98 is obviously 
important. So I think we are free to make a choice about this, but 
personally I don't know which one is "best".

>
>> In my spec, if you omit the package name you get an "old-style"
>> import using the shared namespace, and if you supply a package name
>> you get a "new-style" import that only searches in the specified
>> package:
>>
>>     import A.B.C -- search home + exposed as is done at the moment
>>     import "" A.B.C -- search home package only
>>     import "pkg" A.B.C -- search "pkg" only
>
> That's exactly what our spec says too.  (Good news, again.)  Only
> maybe not explicitly enough!  See the section "Is the from<package>
> compulsory".   Perhaps you could improve the wording to make it more
> unambiguous?

I think it's now explicit enough in the latest version of the wiki - I must 
have replied to your email before re-reading this section. The only comment 
I'd make is that "this" or "home" encroaches on the package namespace so I'd 
prefer "" or a keyword or perhaps a choice of either "" or a keyword just as 
we can use otherwise in place of True in the guard syntax.

>
> Indeed, if we've converged, would you like to fold into our draft
> whatever you think is useful from yours?

Apart from the meaning of A.B.C.id which I don't have a strong view about 
(since I always use aliases anyway) but which other people may also want to 
comment on, both proposals have converged modulo syntax. Therefore it seems 
best to just leave them as they are unless you want to use my suggested 
syntax instead.

Regards, Brian.

-- 
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com