We are moving away from the original question, which was how to keep track of the scope. I would argue that functionality equivalent to the proposed \prop_sput:NNnn exists, as \use:c { prop_#1put:Nnn } with #1 being either { } or { g }. For instance, applying this approach (which is IIRC used in l3keys) to the prop example you gave, we would obtain \cs_new_protected_nopar:Npn \prop_put:Nnn { \@@_put:nNnn { } } \cs_new_protected_nopar:Npn \prop_gput:Nnn { \@@_put:nNnn { g } } \cs_new_protected:Npn \@@_put:NNnn #1#2#3#4 { \tl_set:Nn \l_@@_internal_tl { \s_@@ \tl_to_str:n {#3} \s_@@ { \exp_not:n {#4} } } \@@_split:NnTF #2 {#3} { \use:c { tl_ #1 set:Nx } #2 { \exp_not:n {##1} \l_@@_internal_tl \exp_not:n {##3} } } { \use:c { tl_ #1 put_right:Nx } #2 { \l_@@_internal_tl } } } In low-level code such as this one, I prefer the current approach because it is faster. In higher-level code such as third-party packages, the \use:c approach seems fine to me. The drawback of \use:c will appear if we ever want to attempt some static analysis of the code (if only to know which function requires which, or how to properly indent code), as it is very hard to find out that \tl_set:Nx is called in the above. But I think that it is not such a huge drawback, as it is already unlikely that we can extract much meaningful information from TeX code anyways. I see the other approach (adding 'sput' functions) as having a larger drawback, as it requires adding hundreds of functions (including the inevitable variants). >> I've no real experience of other languages, though, so perhaps I miss >> something. What does one do in say C if the data structures available >> are not suitable? (I didn't think you could even add keywords in most >> languages, so adding data types seems tricky.) > > C is quite old, but even C allows the creation of new datastructures > and control-flow constructs. New keywords can be added with > preprocessor directives (which are very close to TeX command > sequences, actually; both are often referred to as macros). > > What C lacks is encapsulation. Like LaTeX, it has to rely on goodwill > and convention to prevent conflicts. C++ fixed this (somewhat). I think C's structs can be completely emulated using a prop in expl3: of course, that leads to an overhead as the names of the struct entries are stored with the data. Some object ideas I am working on at the moment would alleviate that, storing the entry names once for all structs of the same type. C pointers cannot easily be emulated, as one needs the ability to create unique names (cf. another recent discussion where we concluded that providing a function for that purpose was best). Am I missing some goodies that C provides? While we are talking of datastructure, hence are not very far from objects, let me ask a question: do we want function polymorphism? In other words, do we want the ability for a function to switch behavior depending on the type of its argument, e.g., letting us provide \obj_to_str:N <any object>? Some somewhat-object-oriented languages do not allow this, for instance OCaml will balk at "1.2 + 3.4", and will require "+." instead of "+" for floating points. >> [BTW, I'd hope expl3 is used for 'typesetting', broadly :-) Bruno may >> want to pilot the Mars rover in TeX, but ...] > > TeX is Turing Complete. If you won't exploit it, someone else will. > > Enhanced programming tools help us to build packages that ultimately > make life easier for authors. Below that level, treating TeX like a > general purpose language makes a lot of sense. Isn't that why you guys > are creating expl3 in the first place, and why dialects like LuaTeX > exist? Yes, TeX is Turing Complete, and we do make use of it. One question is to know if we want to go much beyond what C provides (I think we are not very far from covering that) in terms of general-purpose programming tools. Remember that beyond this we also need to worry about tools to handle many other aspects ranging from setting options on a document-wide, environment-wide, or otherwise local basis, taking care of fonts, building paragraphs, maths formulas, tables, and pages from all this, as well as placing figures, understanding the correct approach for letting the user control their placement, etc. There is more than just programming. -- Bruno