LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Javier Múgica de Rivera <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 13 Jul 2006 00:44:06 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (104 lines)
There is a control secuence named \chk_if_exist_cs:N with the following 
definition:

\def:Npn \chk_if_exist_cs:N #1 {
  \if:w \cs_if_exist_p:N #1
  \else:
    \err_latex_bug:x{Command~ `\token_to_string:N #1'~
                     not~ yet~ defined!}
  \fi:}

i.e., if the control sequence already exists it does nothing, but \else
an error is issued. The opposite to \chk_if_exist_cs:N is, amazingly,
\chk_new_cs:N,

\def:Npn \chk_new_cs:N #1{
  \if_meaning:NN #1\c_undefined
  \else:
    \if_meaning:NN #1\scan_stop:
    \else:
      \err_latex_bug:x {Command~name~`\token_to_string:N #1'~
                            already~defined!~
                        Current~meaning:~\token_to_meaning:N #1
                      }
    \fi:
  \fi:
%<*trace>
some code
%</trace>
}

\chk_if_exist_cs:N does the check via \cs_if_exist_p:N, which reverts
\cs_if_free_p:N, which in turn checks that the cs is undefined and not
literally \c_undefined. But \chk_new_cs:N does not!, and it is the one
actually used to test for free commands when new-defining something, so
that something like \def_new:Npn\c_undefined{whatever} would work, and
it shouldn't. From my point of view the definition of \chk_new_cs:N
should obviously be

\def:Npn \chk_new_cs:N #1{
  \cs_if_free_p:N #1
  \else:
    \err_latex_bug:x {Command~name~`\token_to_string:N #1'~
                          already~defined!~
                      Current~meaning:~\token_to_meaning:N #1
                    }
  \fi:
%<*trace>
some code
%</trace>
}

(It looks as if \chk_new_cs:N were created prior to \cs_if_free_p:N and
\cs_if_exist_p:N, and it were not changed in order to take advantage of
these new macros).
I also think that its name should be \chk_if_free_cs:N.

It also happens that all the tests purposed to see if a cs is free, they
test for equality with both \c_undefined and \scan_stop: (\relax). The
logical equivalence of a cs equal to \scan_stop: to a undefined cs is
due to the fact that \expandafter\ifx\csname foo\endcsname creates the
control sequence, and lets it equal to \relax, as we all know, and also
it was common to ``undefine'' a cs by \let\foo\relax. Now we can
undefine via \let\foo\c_undefined (the control sequence \c_undefined is
the most tricky trick I've ever seen. It would have been nice if we had
known it from the begining) and test for the inexistence of a cs with
etex \ifdefined and \ifcsname without creating it, so there is no reason
why to think about someting equal to \scan_stop: as a free cs.
There exist \if_really_free... that do these tests. In my opinion these
should be the normal \cs_if_free..., and nothing with the extrange names
\if_really_free... should exist. So my point of view is:
1. All tests that finally use tex \ifx for free-cs testing should be
replaced by \if_cs_exist:N and \if_cs_exist:w (\ifdefined and \ifcsname)
2. A control sequence equal to \relax being equivalent to a free control
sequence is an accident of the past we should commpletely forget about.

We can think about some examples where a cs equal to \relax is by no
means a free cs, but just something that can be customized, and by
default is equal to \relax, and redefining it could cause major damage.
(For example, the old \@typeset@protect).


Another thing that has nothing to do with the previous one. There have
been in the past many discussions about how to create a realy
multilingual program. One of the points was to allow typeseting cs in
Russian (say), but we cannot simply make the \catcode equal to 11
because then the character would be transparently passed to the dvi
(ie., the font). Can we simply add in etex (or pdftex, or whatever) a
\cscode? Such a \cscode would be equal to 0 or 1, acordingly as to the
characert is allowed in the name of a cs or not (more precisely, a
character with \cscode 1 would make the previous one the last of the cs,
or if it is the first one it would be the only one in the name of the
cs). The setting of the cscodes would be done when selecting the input
encoding.
I think cscodes would make catcodes 11 and 12 equal, or am I missing
something?

p.s. I also thik that names for testing if a certain condition is true
or false should always contain ``if'' to avoid confusion.

p.p.s I will herefrom sign all my e-mails with Javier A., in order to
avoid confusion with Javier Bezos, who entered this list long before me.

Javier A.

ATOM RSS1 RSS2