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:

l3 function names

From:

Date:

Sun, 21 Jun 1998 19:36:28 +0100

Content-Type:

text/plain

Parts/Attachments:

 text/plain (97 lines)
 Hello, I've rewritten some of my own macros -- it's not difficult and... they work! That and the Frank's message convinced me that the argument specifiers could be sometimes a good thing. But... From l3basics: "\let:NwN  \let:NN  \let:Nc  \let:cN  \let:cc" That looks pretty, but it's misleading because it suggests a symmetry which in fact does not exist. \let:NwN expands to itself while the remainder does not. Another example (from "l3expand"): "\exp_args:Nx  \exp_args:Nc" The first one cancels kerning, but the second one does not. When there are some variants, which is the command with the actual definition? More important: How do I remember which variants are available? If I write \def_long:cpn and then I realize that this command should be global I will tempted to write \gdef_long:cpn. It does not exist! Personally, I don't feel like learning the available variants of the commands. I find preferable a set of basic commands and a set of modifying commands as explained below. Renaming commands ~~~~~~~~~~~~~~~~~ Suppose someone is determined to study the internal latex code with the new naming scheme. He take the TeXbook and... surprise! The latex code is absolutely unintelligible. I thing the primitive (and maybe plain) command names should be preserved with perhaps some minute changes; eg. \_box instead of \box (you may think of that as "no module"). However, I think it's not a good idea to change at all the meaning of those well established names. If \box has another meaning it could lead to confusion. Argument specifiers ~~~~~~~~~~~~~~~~~~~~ From expl3: "N Single token (unlike n, the argument must not be sorrounded by braces.)" In fact N stands for: - a token without braces (\def:Npn) - a token with (or without) braces (\def_new:Npn) - a brace (!) (\tokensi\exp_after:NN{\command}) \let:NN{\arg1}{\arg2} is particularly amusing because the first N is \arg1 and the second one is { with an unmatched brace. I think three ideas are being mixed: - How arguments are read:   * A single token without braces   * A single token with or without braces   * A token list (with braces) - How argument are expanded:   * No expansion   * One level expansion   * Full expansion - Conversion from a string to a token (Actually, in my titlesec package I need expand a certain command exactly three times, no less, no more.) 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). Now imagine that there is no : notation and we use the l3expand set of tools. The code will no longer be cluttered with specifiers and in the few places where something unusual is necessary the code will remain readable. For instance (from "expl3"):   \exp_args_Oc \glet \g_reserved_a_tlp \l_current_font_shape_tlp and   \exp_args_cO \seq_test_in {sym#3} \l_group_seq Undescore in names ~~~~~~~~~~~~~~~~~~~ Changing the _ catcode prevents from using explicit subscript characters. I think there are better candidates: "other" character except =, <, >, . (sadly), , (ie, comma), - and +. (Namely /, !, ?, : (already used), ;, @, |...) Regards Javier PS. Frank and Rainer: Thank you for your suggestion, I've sent the command to the server.