David House wrote:
Apologies to Brian for the multiple copies, this wasn't originally
sent to the list.
On 25/06/06, Brian Hulley <[EMAIL PROTECTED]> wrote:
I'm wondering: would it not be easier to just make it that the
package name is prepended to the hierarchical module name, so the
modules would instead be called by the names P.Data.Foo and
Q.Data.Bar?
This has the disavantage that if you move a module from one package to
another, all existing code using that module breaks.
Existing code also breaks when you rename a module, although perhaps that's
not so common as moving a module to another package (it's probably just me
that has a bad habit of always wanting to rename everything later ;-) )
Perhaps we need something analoguous to qualified imports: as well as
specifying the modules hierarchical path, you could also specify its
package. E.g.,
import Network.HTTP from HTTP
Or, using your syntax:
import HTTP.Network.HTTP
[rearranged]
Also, ambiguity. Given 'import
HTTP.Network.HTTP', the compiler has to search for both packages named
HTTP and modules with a full hierarchical name of HTTP.Network.HTTP.
In the unlikely sitatution where a different package did indeed
provide a module called HTTP.Network.HTTP, there would be an overlap.
Finally the compiler could give better error messages if the module
doesn't exist. I.e. one of 'Package X not found' or 'Module Y not
found within package X' instead of 'Module Y not found'.
I agree with the advantages of making the package part explicit for
preventing ambiguity and getting better error messages.
[rearranged]
I prefer mine because we could also allow not qualifying the package:
import Network.HTTP -- will search all known packages for a
Network.HTTP package
This is likely to be less of a pain in the majority of cases when the
module names don't overlap.
I think though that a problem with allowing the package part to be omitted
would be that when code is shared people would get different results when
trying to compile it depending on which packages they happen to have
installed. At the moment, although different packages can define modules
with the same name, everyone afaik takes great care to try and avoid this so
that the hierarchical namespace is hopefully "unique" regardless of the
search order of packages.
However if we are allowed to qualify a hierarchical name by a package name,
we might end up with a lot less "uniqueness" in the hierarchical namespace
(since this is partly the whole point since uniqueness can't be guaranteed
at the moment anyway unless everyone knows about everything that everyone
else is developing or intending to make globally available) leading to more
unintended combinations of modules when they're imported unqualified.
Therefore to get 100% safe code (assuming uniqueness of package names), I
think it would be better to make the package qualification mandatory.
import Network.HTTP from HTTP
import qualified Newtork.HTTP from HTTP as H
Other possibilities:
import HTTP\Network.HTTP
import Com.Company\Network.HTTP
package Com.Company as C -- a package alias
import qualified C\Network.HTTP as H
Not that I'm necessarily suggesting \ but just trying to find some character
that is easy to type (perhaps /) and can also be used in the lexical syntax
without making too much impact on the CFG.
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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
