References: <941aad2c-bc3d-ca7a-1757-470e7ed1d5b9@free.fr>
            <87bmc3ripu.fsf@fencepost.gnu.org>
            <FAFAAEF8-5739-4255-8DB3-EFE2418830E4@wspr.io>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
            Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID:  <6f6508f9-18da-5f27-6cc7-49852890928f@latex-project.org>
Date:         Fri, 22 Jun 2018 10:27:51 +0200
Reply-To:     Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender:       Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From:         Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: Package registration
To:           LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <FAFAAEF8-5739-4255-8DB3-EFE2418830E4@wspr.io>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Am 22.06.18 um 09:16 schrieb Will Robertson:
> On 22 Jun 2018, at 5:54 am, David Kastrup<dak@gnu.org>  wrote:
>> A stupid question that just occured to me: should we be discouraging
>> registering prefixes that match another prefix' contribution to the
>> overly simplistic hash function used in almost all TeX engines?
> Would it be easier to update the hash function in the engines?:)  
> What would be the easiest way to test for clashes?

No change I would think, but does it really matter in all honesty?


However, we should perhaps be in general more selective in what we 
accept instead of a first come first get approach.

For example, if somebody would register "array" for some tiny 
improvement package we should probably object, or in general we should 
take a hard look at anything that is potentially a useful prefix for the 
kernel level, we maybe we should very clearly urge the developers to do 
that same, i.e., ask themselves, is that prefix really  covering just 
the space I like to cover, or is it much broader and I possibly freeze 
up a useful name for a general prefix without ever intending to cover 
that space.

E.g., siunitx is fine (not because it is from a package of JW :-) but 
because that package is the dominant package for that space and 
exhaustive, same with mhchem as it uses the developers initials, but
if somebody adds another argument specifier for array columns in a 
package and uses the prefix "array" for somebody asks for "math", etc 
that  it wouldn't do, imho.

very short abbreviations are perhaps not good too  if there is some 
likelyhood that the sort name  is useful one day for a more general 
purpose. (We do have a small number of those already in l3prefixes)

So something like "statistics" is perhaps not good either unless it is 
intended for a full coverage of the statistics space...  and it might be 
better to have this called jrstat  --- clearly depends, but we should 
probably go into that direction and not accept such prefixes or at least 
get back to the developers with a big question mark

frank