## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: l3 function names

From:

Date:

Sat, 27 Jun 1998 14:36:57 +0100

Content-Type:

text/plain

Parts/Attachments:

 text/plain (162 lines)
 Hello The Frank's letter clarifies me many things. >and typing with a >small child on my lap is ...) I presume a lot harder than with a cat :-) >first of all the basic commands are unchanged availabale all starting >\tex_... (with the idea that perhaps \etex_... or \pdftex_... thingies >exist one day. In this case using \tex_ makes sense, but I presume that tex, etex, pdftex... names will not overlap. For this reason I think removing the "tex" is not a serious problem and this way we avoid the cluttering with "tex"s. There is also the :D convention which suggest that many TeX parameters are functions; eg \uchyph or \parindent. If this notation is to be used in all or none of primitives, I think is preferable in none, because they will not follow neither the function nor the parameter syntax, ie they stand apart. >if the bootstrap of something like L3PL is short and painless you >could start from learning the language itself and nothing else. it >does clearly keep the primitives that should be enough. in other words >i think this is more something for old programmers like you and me >being a *short-term* problem but that should'nt guide us. I'm not convinced. I think that that will make LaTeX a closed world without exchanging ideas and macros with other TeX formats. I'm thinking of EDMAC, ArabTeX or MusicTeX for instance. > > \let:NN{\arg1}{\arg2} is particularly amusing because the first N is > > \arg1 and the second one is { with an unmatched brace. > >indeed. but then you could argue, garbage in garbage out, ie as this >isn't correct input output might be anything. but i know if i argue >this way then you give me > >\let:NN{\arg2 > >which should then work but doesn't either. so???? Of course it does not work because { is not active. The point here is that the opening brace sometimes is ignored, sometimes is not; the closing brace sometimes will be read, sometimes will give an error. > > If specifiers rules are not very, very, very clear it could be interpreted > > in a wide variety of ways by developpers, making the code even more > > unintelligible. I've devised some other specifier schemes but > > inconsistencies > > seems reluctant to disappear (except if a score of specifiers are used). > >not sure i understand that sentence. did you mean you found it hard to >find something that works better without running into different >problems? (that's what we found) Yes, you are right. (English is not my strong point and perhaps I didn't explain myself correctly.) I also mean that if someone interprets the specifiers in a wrong way he could give a misleading name. For example, n instead of N (in fact I've made this mistake when writing some macros. I realized my error when trying to devise other specifier schemes) or argumentless function instead of parameter. >we would certainly welcome suggestions---this is a working draft and >as we say by no means anything that is present as the best and final >thoughts on the subject, though it is true that we have put a lot of >thoughts into it and thrown away many (worse) attempts. Obviously, I cannot try for a complete spec scheme in just a few days, but for example this is the best idea I had (so far and by far) spec arg forms meaning ~~~~ ~~~~~~~~~ ~~~~~~~~ u \cmd unexpanded/unbraced token n \cmd {\cmd} token name c \cmd {\cmd1\cmd2...} container; the contents will be passed as argument   [\expandafter{\cmd}] l \cmd {\cmd1\cmd2...} token list x \cmd {\cmd1\cmd2...} expanded token list n and c have the "string" variants N [\expandafter{\csname str\endcsname}] and C [\expandafter\expandafter\expandafter{\csname str\endcsname}]. Perhaps also: S string containter in string form   [\expandafter\expandafter\expandafter           {\expandafter\csname\csname str\endcsname\endcsname}] An hypothetical no string form (s) is equivalent to N; there is also p, t, f, w. I was looking for some symmetry in the meaning of uppercase letters; here uppercase means "string form". So we have for instance \let:uwu \let:nu \let:Nu \let:nN \let:NN \exp_after:uu \def:upl \def:upx \def:Npl \def:Npx. As you can see nothing new, except the letters used and the u spec. A further spec is to be used with \exp_args: d \cmd {\cmd} dormant; usually n but it will not be expanded                      in protected expansions. Its definition could be something like:   \def\:::#1{\exp_not:N#1}   \def\::d#1\:::#2#3{#1\:::{#2\exp_not:N#3}} with the corresponding tests to see if the protection is enabled. The string variant (D) can lead to confusion. For example    \exp_args:nd\def:npl\cmd{...} is right, but    \exp_args:nD\def:Npl{str}{...} expands to \def:Npl\str, which is wrong. If the modifiers + basics scheme is used this problem does not exist: \exp_args_d\def\cmd and \exp_args_D\def{str}. These ideas should be thought out if they seem interesting. Actually, the problem is always present if diferent variants of \exp_args and command specs are mixed: \exp_args:Noox\cmd:nNxn... What? :-) ) The answer of exercise 9.8 from the TeXbook is to the point. Why \'#1 and not simply \'? "An argument makes the use of \' more consistent with the use of other accents like \d." This idea may be applied to the \def: functions. So \def:Npn #1{\tex_def:D #1} instead of \let:NN\def:Npn\tex_def:D. In the notation above that gives \def:npl \def:npx \def:Npl \def:Npx. >well, my experience is that having the number of arguments clearly >attached to a command makes things much more readable than not having >it (ie \seq_test_in:nn compared to \seq_test_in) --- after getting >used to it this was a very helpful feature in reading code by others. If you want to understand a function you must read its definition, and then you see its arguments, making the specs a bit redundant. And when I see things like \titlesec_sect:nnnnnnnn I am horrified. Up to now I have not get used to it. Perhaps in a few years... ;-) >as for the _ not being available as an explicit subscript: > >we don't consider this significant as we think that this should be >done this way anyway. the few places where you really need a subscript >in a macro you can as well use some slightly more complicated way (in >plain TeX this would be \sb) \sb is not an explicit subscript char. I cannot say, for instance \def:Npn \get_token:n #1{  \if:w \str_eq_p:nn {#1} {\sb} etc to test if the token is _. I presume that the \lccode / \lowercase trick will be necessary. (Or thinking in terms of the new syntax (expandable version):   \if:w \exp_args:No \str_eq_p:nn {\sb_char} {#1}... where \sb_char contains an actual subscript char. But I find clearer   \if \exp_args_o \str_eq_p {\sb_char} {#1}...) (Actually, \str_eq_p is great. I've had using for years the \if\test device in my own TeX macros. I think it's one of the most interesting aditions, besides the l3expand module and the fint type.) >thanks for all the comments (hope to get more) You are welcome... and l3 as well (no doubt) Ragards Javier