LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced 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
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 15 Apr 2014 11:41:17 +0200
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=ISO-8859-1; format=flowed
Frank Mittelbach <[log in to unmask]>
text/plain (63 lines)
Am 14.04.2014 15:30, schrieb Lars Hellström:

> The typical example of this would be a callback function: something
> that a module calls at specified points, but which the user of that
> module is expected to define. Treating this as just a function loses
> the specification of the scope for that variable. Treating it as a
> variable of type tl loses the specification that it takes arguments.
> What I found natural is to use a name of the form
> e.g.
> \l_harmless_callback:nn
> This could be interpreted both as adding a SCOPE part to function
> names (the vast majority of functions without a SCOPE are implicity
> considered to be c_ constant), or alternatively as proclaiming any
> :<ARG-SPEC> to be a valid _<TYPE> for a variable.

that's an interesting point. I'm a little torn over this to be honest.
On one hand I rather like the idea to mark functions that are supposed
to be defined/manipulated by a user of a package specifically but on the
the other hand I'm not so sure the suggested convention would work
nicely in practice as it blurs the  distinction between traditional
"data" variables a bit and I'm not sure how that would work out (though 
that is something to  experiment with I guess).

if that suggestion is taken up then


with <SCOPE>_  being either l_ or g_ sounds fine (the majority of 
functions are supposed to be constant so c_ should definitely implicit 
in my opinion)


\l__<MODULE> or \g__ should never been allowed as module internal 
functions by definition should not be a user or programmer outside the 

One question to keep in mind though is do we really would see both l_ 
and g_? r would we see many of them at all? If a package expects a 
number of such "variable functions" to be set up before some of its 
interfaces can be used then you have the issues of state/scope to deal 
with and the fact that such a package could be used by several other 
packages etc. In that case I wonder if it wouldn't be better to 
encapsulate the setup by providing a setup function and use an internal 
function for the "variable function" (in which case the direction would 
then be somewhat opposite, ie we would suggest to use \l_@@ and \g_@@ 
for the variable functions and the setup function would become an 
unchangeable constant function taking code as arguments

Speaking of "user": we are talking here "user" as in programmer of some 
other package using the former one, not end user using document level 
customizations. Because for those I would maintain that no expl syntax 
should leak and any such customizable function would need to be 
encapsulated by a proper interface - at least this is my take on this