LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Content-Type: text/plain; charset=ISO-8859-1
Date: Tue, 27 Dec 2011 23:14:27 +0000
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
Content-Transfer-Encoding: 7bit
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Joseph Wright <[log in to unmask]>
Parts/Attachments: text/plain (64 lines)
Hello all,

We currently have a few functions in l3token for creating definitions
for active characters. These are defined as 'experimental', and I was
recently asked about them and so though it might be worth raising the
issues here. (I've also done a little tidying: in the following I'm
referring to the SVN/GitHub version of the code rather than the last
CTAN snapshot.)

The current implementation provides \char_(g)set_active:Np(n|x) and
\char_(g)set_active_eq:NN. The logic to these functions is that they set
the N argument active (locally) then attach a definition either locally
or globally as appropriate. Thus \char_set_active:Npn is equivalent to
the inline code

  \char_set_catcode_active:N <token>
  \cs_set:Npn <token> <parameters> { <code> }

and so forth.

There are a few questions this raises. To cover all possible cases,
you'd need ..._nopar..., ...protected... and ...protected_nopar_...
versions, which looks a bit like overkill. (Well, perhaps only
protected, as we are de-emphasising nopar, but even then the point
stands.) Secondly, you often want to set up the definition of an active
character in advance of making the character active, and may want to
make the character only 'math active'.

There's also a conceptual issue, in that the LaTeX3 programming approach
is in general to use well-defined function names for everything,
including having arg specs and the like. That seems to fit poorly with

That suggests to me that we should perhaps avoid attaching definitions
to active characters directly. That leads to a sequence something like

  \cs_new_protected:Npn \mypkg_foo: { <code> }
  \char_set_active_eq:NN <token> \mypkg_foo:

This would then leave the question of whether the later function should
both make <token> active /and/ assign the definition, or only assign a
definition to <token> to be used if <token> is later made active (with

The advantage to separating out the 'make active' and 'what to do when
active' steps seems to me to be that it keeps life simple for math
active characters. We've not yet addressed math codes in expl3 in any
serious way, so at present you'd need

  \cs_new_protected:Npn \mypkg_foo: { <code> }
  \char_set_active_eq:NN <token> \mypkg_foo:
  \char_set_mathcode:nn { `\<token> } { "8000 }

I'd also say the naming is not so bad - \char_set_active_eq:NN for 'sets
the behaviour of the character /when active/' and
\char_gset_active_eq:NN for 'globally ...'.

Does this make any sense? It essentially simplifies the current
experimental code, but also should make it more generally useful.
Joseph Wright