LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Fri, 22 Jun 2018 09:59:28 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
text/plain; charset=utf-8; format=flowed
From:
Joseph Wright <[log in to unmask]>
Parts/Attachments:
text/plain (68 lines)
On 22/06/2018 09:27, Frank Mittelbach wrote:
> Am 22.06.18 um 09:16 schrieb Will Robertson:
>> On 22 Jun 2018, at 5:54 am, David Kastrup<[log in to unmask]>  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

We discussed this when I first raised the idea of a list. Unlike some 
other areas (e.g. Python code and CPAN), there are no formal 
requirements for distributing (La)TeX packages. More importantly, CTAN 
set their own approach independent of the LaTeX team.

Thus the aim of a prefix database is necessarily more 'for information' 
than anything 'stronger'. I think if something was requested which 
looked extremely problematic, a registration request would be a good 
opportunity for discussion. Ultimately, however, the prefix is down to 
the package author: it's no good saying 'no we won't log it', only for 
the package to go to CTAN anyway but ending up that bit harder for other 
developers to see.

There are a few names that the team have put down already as 'reserved' 
which are not in use ('font' is the obvious one). I suspect that other 
*very* general ideas could also reasonably be 'held': there would be 
nothing stopping the team later 'giving up' such prefixes if a 
reasonable argument were made for it.

In the case in hand, whilst 'statistics' is quite general, it's also 
pretty long and there are a number of alternatives ('stats' or 'stat' 
the two most obvious).

Joseph

ATOM RSS1 RSS2