[cc'ing to the Haskell mailing list] S. Alexander Jacobson schrieb: > A while back, I had been arguing on the Haskell mailing list that module > meanings were not and should not be qualified by package names.
It cannot be argued that introducing a package system does nothing in terms of disambiguating modules except adding a new top level to the existing hierarchy. Then it must be argued whether this is a good idea or not. My current standpoint is that packages make sense as distributional units (at least in some cases - haven't thought this through), but give no real solution to the problem of managing the module namespace. In the latter respect, I think the only solution is to explicitly partition the namespace by author or organization - the same effect as the Java style of embedding DNS domain names in the module namespace. I find the Java way very ugly, though. But as you surely know, current Haskell practice already is to place a module into the hierarchy in some seemingly appropriate place and suffix it with, say, the author's name or some other characteristic identifier to avoid clashes. I tend to think this is a good scheme. For it to _really_ work, however, we should form a registry of "officially assigned" module names (i.e. ones without a disambiguation suffix) and also one for the author and/or organization names to be used as suffixes. I for example am known by the nickname Pesco, or (more recently) by the mnemonic SM at domain KHJK.ORG. So I could register - Pesco as a (personal) disambiguation suffix or - KHJK as an (organizational) suffix. The latter case would put the management of the KHJK subnamespace under organizational control and I could, in this example, use KHJK.SM for my personal use, or just KHJK (if the organization agrees). > I just > read your ECT article which seems to start with the same assumption and > takes the theory to its logical conclusion. I take that as a compliment. ;) Thank you. > On my end, I decided to implement a tool that shows why packages are not > a good model for versioning and implemented SearchPath > (http://searchpath.org). SearchPath takes a map of module locations on > the Internet and does automatic import chasing for your particular > application. Cool, nice work! I've actually thought about building a system just like this. > In your ECT article you say: > > In the long run, I envision a world where I can stumble across some > module on the Net, immediately import it in my code, and, on the > stroke of a single command, have my system locate, fetch, compile, and > install that module, dropping me at an interactive prompt with the new > import available! All of the above without having to worry about > whether or how to bundle that module with my code, prompted by > questions of its availability and compatibility on my users' hosts. > > I think SearchPath helps get us there. I am soliciting any thoughts you > may have to improve SearchPath and better integrate it with people > implementing ECT in their modules. The main issue that springs to my mind is authenticity control. How do I know the module I'm downloading is the one I want? Note that this question is always there, even in the local case, but it is usually not seen as a problem until module sources are distributed over the Net. The issue of course boils down to establishing trust. Oh, I just remember Raph Levien of advogato.org complaining about his trust metrics not being used! Maybe that would be an idea... - Module authors PGP-sign their code. No problem. - Module importers check their imports for trusted signatures. Hm. - To trust a signature means to a) trust that it belongs to the author it claims to belong to, b) trust that author to produce "friendly" code. Here's where trust metrics could be employed. The PGP web of trust already does it for (a) and (b) would be to do by us. Does the following make sense? Or is there an elegant way to make this not rely on the central registry for authority? - Module importers also check their imports against the registry. - The registry records for each "block" of the module namespace, the author/organization - identified by key - responsible for that block. I don't have time just now to think through these things. But many thanks for your mail, and keep going. I'm sure we can devise some brilliant way to solve all these problems -- in theory ;) . Regards, Sven Moritz
signature.asc
Description: PGP signature
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
