Name allocation (was: RE: Haskell library infrastructure coordinator)
Peter Simons writes:
I'd like to have complementary libraries in there. For instance: I have written a set of QuickCheck combinators, which can be used to generate random expressions to test parsers. If this were to be added to "hslibs", it would probably go to "Debug.QuickCheck.Parser".
Of course, we could add a prefix like "HSLibs" to _all_ libraries included in the repository, to make sure they don't collide with the standard ones, but IMHO this is overkill.
It's also not a guarantee that your libraries won't collide. The only way (currently) to have such a guarantee is to use User.To.Cryp.Simons as the root of your library tree. Perhaps there's a demand for a part of the hierarchy that is a "free for all", with no formal process for acquiring names, where collision is "at your own risk". Suggestions for the root name for this hierarchy are welcome: Unstable or Temp perhaps? Cheers, Simon
Simon Marlow writes:
The only way (currently) to have such a guarantee is to use User.To.Cryp.Simons as the root of your library tree.
Does this really guarantee uniqueness? What if I don't own a domain name personally? What if I give up my domain and somebody else buys it? What if somebody doesn't know of this convention and simply uses this exact name because he likes it? As far as I can tell, you cannot guarantee unique names at all if your name space system has an absolute root -- like Haskell does. Whatever you come up with may potentially clash with someone else's name -- and probably will. :-) The only way to guarantee unique names -- without requiring people to abide to some "arbitrary" convention -- is the module names to be relative. If I import a module "Foo.Bar", and I am "Peter.Simons.ToolXY", then this module will be "Peter.Simons.Foo.Bar" for me. In such a system I can uniquely access any module, no matter how it's called. So if we _need_ a convention to guarantee unique names (within our convention), any one is as good any other -- technically speaking. And IHMO the simplest possible convention for a source repository we could provide is: Call it whatever you like, as long as it begins with "Unstable" and it is not taken yet. To refer to current practice one more: This is exactly the way domain names are handled, and despite all the problems, it has worked pretty good so far.
Perhaps there's a demand for a part of the hierarchy that is a "free for all", with no formal process for acquiring names, where collision is "at your own risk". Suggestions for the root name for this hierarchy are welcome: Unstable or Temp perhaps?
I think "Unstable" is a pretty descriptive name. Or maybe "User"? The latter is probably better for psychological reasons. :-) Peter
Peter Simons
I think "Unstable" is a pretty descriptive name. Or maybe "User"? The latter is probably better for psychological reasons. :-)
I've said this privately, I think, but I think it may be worth repeating in public: I like "Unstable" as an analogue to unsafe* (as in unsafePerformIO). It sticks out like a sore thumb in source, making it very clear that it may be dangerous to rely on. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
On Friday 30 May 2003 3:45 am, Peter Simons wrote:
The only way to guarantee unique names -- without requiring people to abide to some "arbitrary" convention -- is the module names to be relative. If I import a module "Foo.Bar", and I am "Peter.Simons.ToolXY", then this module will be "Peter.Simons.Foo.Bar" for me. In such a system I can uniquely access any module, no matter how it's called.
Maybe I need more coffee but I don't see how using relative names helps with the hard bit of the problem: conflicts between libraries written by different people. Suppose module Peter.Simons.ToolXY wants to import Alastair.Reid.Foo.Bar (which is meant to mean the library written by me), but someone else by the name of Alastair Reid (e.g., the poet/ author who translates Neruda and Borges from Spanish to English) has also written a library called Alastair.Reid.Foo.Bar. It's all very well saying that inside your library the library is called Peter.Simons.Foo.Bar but that doesn't seem to address the issue that there is an ambiguity that has to be resolved. -- Alastair Reid
Alastair Reid writes:
Maybe I need more coffee but I don't see how using relative names helps with the hard bit of the problem: conflicts between libraries written by different people.
All you'd have to do is to put the two conflicting libraries into separate directories, than you could import them using: import A.Foo.Bar import B.Foo.Bar The reason this does not work as-of-now is the requirement of an absolute path in the module declaration. And relative paths would fix this. Peter
At 03:16 03/06/03 +0200, Peter Simons wrote:
Alastair Reid writes:
Maybe I need more coffee but I don't see how using relative names helps with the hard bit of the problem: conflicts between libraries written by different people.
All you'd have to do is to put the two conflicting libraries into separate directories, than you could import them using:
import A.Foo.Bar import B.Foo.Bar
The reason this does not work as-of-now is the requirement of an absolute path in the module declaration. And relative paths would fix this.
This resonates with me. I recently converted a codebase from using "flat"
to hierarchical libraries. I hoped that some additional libraries I use
(HUnit, Parsec) could also be installed in the library hierachy tree, but
that wasn't to be. I think for exactly the reason suggested here;
everything works fine when I set up explicit paths for the extra libraries,
but I think that could get unwieldy for a large project.
#g
-------------------
Graham Klyne
Peter Simons
Maybe I need more coffee but I don't see how using relative names helps with the hard bit of the problem: conflicts between libraries written by different people.
The reason this does not work as-of-now is the requirement of an absolute path in the module declaration. And relative paths would fix this.
I would like relative names. I've used them in Python for years, they're very handy. Would relative names be nonportable or difficult to implement? -- Shae Matijs Erisson - I've tried to teach people autodidactism, but it seems they always have to learn it for themselves. #haskell on irc.freenode.net - We Put the Funk in Funktion
On Fri, May 30, 2003 at 04:45:05AM +0200, Peter Simons wrote:
Simon Marlow writes:
The only way (currently) to have such a guarantee is to use User.To.Cryp.Simons as the root of your library tree.
Does this really guarantee uniqueness?
No, but if your email address is given to someone else, then possible namespace conflicts in software modules are going to be the least of your problems. Lauri Alanko la@iki.fi
participants (7)
-
Alastair Reid -
Graham Klyne -
ketil＠ii.uib.no -
Lauri Alanko -
Peter Simons -
Shae Matijs Erisson -
Simon Marlow