This page is part of the web mail archives of SRFI 84 from before July 7th, 2015. The new archives for SRFI 84 contain all messages, not just those from before July 7th, 2015.
Michael Sperber asked me what my intentions were with respect to SRFI-84 Universal Identifiers. I believe (at least) two of the criticisms of the current draft of SRFI 84 raised on the email list are fundamentally correct: * Categorizing libraries (for example, "math", "parsing", "web", etc.) should be done outside of a system for creating unique, universal identifiers for libraries, because you might want to reorganize your library categories at some point, or support several different ways of categorizing libraries. * Basing library identifiers on globally assigned identifiers (such as domain names or email addresses) is problematic, because you may stop using or lose control of your domain name or email address. (And it just moves the responsibility for getting you a unique identifier on to some already existing system such as the domain name system). The "petname" approach strikes me as potentially brilliant, promising to remove an entire class of problems around naming and identifies, just as, by analogy, garbage collection removed an entire class of problems around dangling pointers and reclaiming unused memory. However, I personally have neither the time, skill, or expertise to attempt to create a petname system for naming and identifying libraries. Thus, in conclusion, I have nothing to add! I can neither recommend the current draft of "Universal Identifiers" (given the problems revealed through discussion on the email list), nor attempt to implement a better solution myself. I thank everyone who contributed to the discussion. I found the comments and suggestions offered by you on the email list to be insightful and inspiring. The question of how to name and identify libraries will only loom larger as the number of libraries written by programmers increases at a faster rate. If you (or someone you know) is looking for a problem to solve to contribute to the state of the art in computing, consider reading the email discussion for the useful ideas published there. Thank you, Andrew Wilcox