[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
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
