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 > > \<SCOPE>_<MODULE>_<DESCRIPTION>:<ARG-SPEC> > > 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 \<SCOPE>_<MODULE>_<DESCRIPTION>:<ARG-SPEC> 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) also \l__<MODULE> or \g__ should never been allowed as module internal functions by definition should not be a user or programmer outside the package. 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 cheers frank