Sun, 17 Mar 2013 11:35:06 +0000
On 17/03/2013 10:28, dongen wrote:
> : for that reason I don't think that the introduction of another aux
> : type file is warranted it would be something only needed for
> : managing the register but required all over the place. In contrast,
> : if you just have a formal specification, you could regularly build
> : the register by scanning across all dtx ctan files.
> Yes. That's another possible way. I think the main question is
> ``Who wants to be the prefix database manager?''
That we have an answer to: me :-) (Or at least I'm prepared to do it as
I see long-term utility in being able to look up what is in use and who
is using it.)
> : >You can even make the kernel method reject existing prefixes. (Of course
> : >this would mean the method needs some way to access a local copy of the
> : >prefix database....) This may save the programmer precious time and
> : >troubles.
> : I don't think we want to reject prefixes. We encourage not to use
> : existing ones, but there will be a time when this is needed and
> : wanted. And in some cases reuse to "extend" a code base will also
> : come into play. And how would you want to communicated with a
> : developer? if you issue a warning then if it is deliberate you will
> : need a way to get rid of it and such a warning should not show up
> : (imho) for a normal user. At least not against the register as such.
> : Perhaps on the level of what prefixes got loaded into the document,
> : but even then you would need to resolve a situation where (for good
> : or bad reasons) a prefix is shared deliberately between packages.
> When I wrote about rejection, I wanted to point out the
> possibility. Of course you can also inform the package
> writer. Informing the programmer is probably a better way.
Rejection is perhaps a strong term: I'd hope we can look to talk with
programmers to make the best use of the namespace.
> : so I guess food for more thoughts here, but a formal and parseable
> : interface on kernel level may be a good idea, even if we do not
> : directly use it to produce any external code or register
> : updates/queries from within TeX
> You could also introduce a kernel API to formally determine
> the package writer, contact details, package dependencies,
> and so on (all on a voluntary basis). This would really be
> useful information.
Much as I'd imagined: see my other mail.
What I do notice is that there does seem to be some feeling this is a
good idea, both within the TeX community and as I've pointed out based
on what other groups do (particularly Perl).