On 12/07/2013 16:56, Michiel Helvensteijn wrote:
> Hello all,
> It occurs to me, as I write my new expl3 datastructure, that the
> current convention for specifying and propagating 'global'ness of a
> function (namely, by inserting a 'g' in the name somewhere) leads to
> either code duplication or to the definition of boilerplace auxiliary
> functions. It is also too easy to get copy-paste-happy and forget to
> add a 'g' in an implementation somewhere.
Certainly see a point here, but on the other hand I'm not a fan of
encouraging more and more data structures. Writing a full data structure
module is non-trivial: in most cases, I'd expect people to be using
combinations of the existing ones in an ad-hoc fashion for their purpose.
> To encapsulate that detail and to save typing, I furthermore suggest
> that functions like `\cs_new_protected(_nopar)_scoped:NpnNN` are made
> available. To demonstrate their use, I compare the current `\prop_put`
> definitions with the new ones I propose:
This doesn't quite work, as \cs_... should be 'generally for commands',
not just 'for commands that are for variables'. Presumably something
inside \prg_... might be suitable.
> Note that `\tl_sset:NNx` and `\tl_sput_right:NNx` are now spelled out
> in their proper place, so the reader doesn't have to go back and forth
> to understand what's going on. There is no need for auxiliary
> functions and errors of omission are unlikely, since omitting #1 would
> lead to an error.
One of the reasons we decided against auto-detection in some other cases
(I forget exactly where) is that something like \tl_set:Nn can be used
with things that don't follow the naming convention (e.g. user-level
command names). So you can't rely on
for picking up scope. (While we've not worked it through yet, at some
stage we need a document-level token list equivalent, and an interface,
and that will have to use \tl_set:Nn internally, for example.)
I'd also note that 'the reader' should be a small set of people, if we
are doing our job right. The idea is that the docs for expl3 should be
clear enough without people having to read the code. Now, that's not
always true and there are some notable gaps, but I'd hope we can fix
those at the doc. level as people raise them.