RE: Heirarchical name space allocation
Who's in charge of allocating names in the hierarchical modules for publicly released libraries these days?
This page lists (some) allocated names.. http://www.haskell.org/~simonmar/libraries/layout.html
But I can think of a few that aren't listed there. What's the policy? Is there a master reference or register somewhere?
At one stage we thought that having a single global registry for names was the way to go. Now I think that a free-for-all, with good package management tools, is probably better. Names and hierarchy locations will still be discussed on this list, but anyone is free to publish a library using any names in the hierarchy they please. If there is overlap, then the compiler should prevent you from using two overlapping packages at the same time. In fact, there's one good reason for allowing overlap: versioning of libraries. Of course, if your library uses names that are consistent with the general policy, then there's a greater chance that your library will be included in future "collections" of libraries, bundled with compilers, and so on. The idea is that community self-organisation replaces strict central registration of library names. I think this is an improvement, but perhaps it's a cop out. What do others think? Cheers, Simon
Simon, Have you given any thought to adding some security to go along with library versioning? I'm thinking of something like the C# repository, where the version of the library you compile against has a digital signature, and the signature is embedded in the app. The point is to prevent an attack where someone substitutes another library, with the same version information and public interface, and hijacks your code. Seth On Mar 30, 2004, at 2:19 AM, Simon Marlow wrote:
Who's in charge of allocating names in the hierarchical modules for publicly released libraries these days?
This page lists (some) allocated names.. http://www.haskell.org/~simonmar/libraries/layout.html
But I can think of a few that aren't listed there. What's the policy? Is there a master reference or register somewhere?
At one stage we thought that having a single global registry for names was the way to go. Now I think that a free-for-all, with good package management tools, is probably better.
Names and hierarchy locations will still be discussed on this list, but anyone is free to publish a library using any names in the hierarchy they please. If there is overlap, then the compiler should prevent you from using two overlapping packages at the same time. In fact, there's one good reason for allowing overlap: versioning of libraries.
Of course, if your library uses names that are consistent with the general policy, then there's a greater chance that your library will be included in future "collections" of libraries, bundled with compilers, and so on. The idea is that community self-organisation replaces strict central registration of library names. I think this is an improvement, but perhaps it's a cop out. What do others think?
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
!DSPAM:40693bf2325371814315599!
Seth Kurtzberg MIS 480-661-1849 seth@cql.com
On Tuesday 30 Mar 2004 10:19 am, Simon Marlow wrote:
The idea is that community self-organisation replaces strict central registration of library names. I think this is an improvement, but perhaps it's a cop out. What do others think?
I think there should be some concensus about the overall structure of the hierarchy, and that should be documented somewhere (so developers don't go and reinvent their own slightly different names for concepts which are already covered). Perhaps it would suffice to just do this for the top level classifications. In my case I have a pretty complete binding to SDL which I was thinking of tidying up and releasing for other Haskellers. I call it HSDL :-) But should it go in the Graphics Heirarchy, if so where? Graphics.HSDL? SDL also covers other functionality (like audio) so I was thinking of calling it Multimedia.HSDL, but at present there's no Multimedia top level AFAIK (but then how would I know anyway?). Perhaps someone's already using Multi_Media instead? Or maybe my binding isn't necessarily unique, so perhaps Multimedia.SDL.HSDL? SDL also has quite few bolt on extras too which other people might write bindings for. On reflection I'm inclined to favour a centralised system where people book the name space they want and can also check what other libraries already exist or are in development (might help avoid unnecessary duplication of effort if 2 people were unknowingly working on essentially the same library). BTW, is anybody working on a binding of FreeType by any chance? :-) Regards -- Adrian Hey
Adrian Hey
But should it go in the Graphics Heirarchy, if so where? Graphics.HSDL? Or maybe my binding isn't necessarily unique, so perhaps Multimedia.SDL.HSDL?
In general, the package name (e.g. HSDL) does not need to be part of the hierarchical name (e.g. Multimedia.SDL is quite sufficient). This is especially the case when the package is a binding to some external library, which already has its own arbitrary name (e.g. OpenGL, GTK, SDL), and where there is usually only one plain and obvious way (more or less :-) to bind the signatures. However, it /is/ a good idea to include the package name as part of the hierarchical name when (a) the functionality is implemented all or primarily in Haskell; and (b) there clearly exist different approaches to doing the same job. Examples of this are parser combinators, pretty-printers, XML transformation etc.
but at present there's no Multimedia top level AFAIK (but then how would I know anyway?).
This list is the primary forum for the community to discuss and allocate names. So you are doing the right thing by posting a proposal here, with alternatives, and asking for opinions. Regards, Malcolm
participants (4)
-
Adrian Hey -
Malcolm Wallace -
Seth Kurtzberg -
Simon Marlow