gmane.comp.tex.latex.latex3

Should l3keys provide a key .initial:n?

Marco Daniel — 2012-05-26T15:12:34

Hello,

Today I noticed that there is no key .initial:n. This question popped up 
during writing a small package. Whatever at the moment you have the 
following possibilities to set a key-value-syntax with an initial value:
=======================================================================
%First approach:

\keys_define:nn { module }
  {
   myoption .int_set:N  = \l_modul_myoption_int
  }
\keys_set:nn  { module }
  {
   myoption = 2
  }
\ProcessKeysOptions { module }

=======================================================================
Second approach

\keys_define:nn { module }
  {
   myoption .int_set:N  = \l_modul_myoption_int ,
   myoption .default:n  = 2
  }
\keys_set:nn  { module } { myoption }
\ProcessKeysOptions { module }

=======================================================================

I suggest to define a new key .initial:n so that we have a third approach:

Second approach

\keys_define:nn { module }
  {
   myoption .int_set:N  = \l_modul_myoption_int ,
   myoption .initial:n  = 2
  }
\ProcessKeysOptions { module }

=======================================================================

I hope my question is clear.

Of course the current methods are separating the definition and setting 
of keys. In this way it's clear. However I'd prefer the third approach
to set an initial value immediately after their definition.

What do you think about such a key?

regards
Marco

Deprecated functions

Joseph Wright — 2012-05-23T21:09:01

Hello all,

The following functions have been deprecated and will be removed after
2012-08-31 with no replacement direct:

  \clist_use:N
  \seq_use:N

The appropriate alternatives at present are

  \clist_map_function:NN <argument> \use:n
  \seq_map_function:NN   <argument> \use:n
--
Joseph Wright

Deprecated functions

Joseph Wright — 2012-05-13T09:07:26

Hello all,

As notified previously, we are updating expl3 to address a small number
of inconsistencies in function naming. At present, these changes have
been made in the SVN only: they will be updated on CTAN /after/ the
TL2012 freeze.

The following functions have been deprecated and will be removed after
2012-08-31 with no replacement:

  \clist_if_eq:NN(TF)
  \skip_if_infinite_glue:n(TF)

The following functions have been renamed and are deprecated for removal
after 2012-08-31:

  \tl_length_tokens:n => \tl_count_tokens:n

The following functions have been renamed and are deprecated for removal
after 2012-11-30:

  \clist_length:N => \clist_count:N
  \clist_length:c => \clist_count:c
  \clist_length:  => \clist_count:n
  \prop_del:Nn    => \prop_remove:Nn
  \prop_del:cn    => \prop_remove:cn
  \prop_del:NV    => \prop_remove:NV
  \prop_del:cV    => \prop_remove:cV
  \prop_gdel:Nn   => \prop_gremove:Nn
  \prop_gdel:cn   => \prop_gremove:cn
  \prop_gdel:NV   => \prop_gremove:NV
  \prop_gdel:cV   => \prop_gremove:cV
  \seq_length:N   => \seq_count:N
  \seq_length:c   => \seq_count:c
  \tl_count:N     => \tl_length:N
  \tl_count:c     => \tl_length:c
  \tl_count:n     => \tl_length:n
  \tl_count:V     => \tl_length:V
  \tl_count:o     => \tl_length:o

Functions moved to 'internal'/deprecated

Joseph Wright — 2012-05-10T07:22:51

Hello all,

The functions \cs_get_arg_count_from_signature:N and
\cs_split_function:NN have been move to 'internal' status, and so may be
renamed or dropped in the future without notice. These functions are not
used outside of the kernel in a current TeX Live installation.

The functions \cs_get_function_name:NN and \cs_get_function_signature:NN
are deprecated, and will be removed from expl3 by 2012-08-31. These
functions are entirely unused in a current TeX Live installation.
--
Joseph Wright

Upcoming changes

Joseph Wright — 2012-05-10T06:43:06

Hello all,

The team will not be updating the CTAN release of LaTeX3 until after the
upcoming TeX Live freeze. We have some 'breaking' changes that we feel
need to be made, and programmers will need time to adjust their code to
match. In particular, we are keen that the same conventions are used as
far as possible across expl3, and after a careful review by Frank
Mittelbach we have found a small number of inconsistencies which we want
to address.

I will be making a series of announcements over the coming couple of
weeks concerning deprecated functions, with associated renaming where
appropriate. These will all go to CTAN at the same time, and so I will
also announce when this happens, probably some time in June.

One change which has already occurred in the SVN version of LaTeX3 is
the replacement of the 'old' FPU with a new expandable version. We are
currently finalising the details of which functions will be retained and
which will be removed. A full announcement on this will follow in due
course as part of this wider process.
--
Joseph Wright

Babel

Javier Bezos — 2012-05-01T08:28:02

Babel gets back on track and it is again actively maintained. The
goals are mainly to fix bugs, to make it compatible with XeTeX and
LuaTeX (as far as possible), and perhaps to add some minor new
features (provided they are backward compatible).

No attempt will be done to take full advantage of the features
provided by XeTeX and LuaTeX, which would require a completely
new core (as for example polyglossia or as part of LaTeX3).

Your comments or suggestions (or questions!) are welcomed.

Javier

XMLTeX htmlentities.tex

William Adams — 2012-03-07T13:13:01

Returning to working on an xexemltex project and I've found that I 
added a line: 
\input{htmlentities.tex} 

at the beginning of my .xmt file and I'm not remembering if it's a 
standard thing or no. 

It started w/: 

\XMLentity{apos}{\textquoteright} 
\XMLentity{rsquo}{\textquoteright} 
\XMLentity{lsquo}{\textquoteleft} 
\XMLentity{rdquo}{\textquotedblright} 
\XMLentity{ldquo}{\textquotedblleft} 

and I've already added: 

\XMLentity{nbsp}{\nobreak{ }\nobreak} 
\XMLentity{mdash}{\textemdash} 

Should I continue along these lines (and then upload to CTAN?) or is 
there a finished version of this file extant already? (I looked and 
couldn't find one). 

Thanks!

William

Deprecated functions: \prg_quicksort: family

Joseph Wright — 2012-02-08T21:22:23

Hello all,

The \prg_quicksort: family of functions have been deprecated, and will
be removed from l3kernel on or before 2012-05-31.

Non-expandable but clearer functions are available in the experimental
l3sorrt, recently added to the LaTeX3 CTAN bundle.
--
Joseph Wright

Trees, was Re: Mapping Functions Versions for All and Some

Bruno Le Floch — 2012-02-02T18:24:05

Hello Lars,

The Church Boolean discussion is not forgotten, just on the
back-burner with so many things at the same time. It seemed to bring
some performance improvements, but there were some awkward parts to it
in the way I initially tried to implement them. In your last email on
the topic a few months back, you had a better approach some working
code, which I didn't get to benchmark carefully. I definitely need to
get back to boolean expressions, since at the moment
(...)&&(...)||(...)&&(...) treats && and || with the same priority,
which is wrong. Perhaps that will mean switching to Church booleans,
perhaps not: there are a lot of issues to consider, including
bootstrapping expl3, having a nice interaction with (future) fp
expression, no breaking change, etc.


I'm interested in what you have to say about 2-3 trees. I implemented
sorting based on splay trees, which I think I will also use for
Unicode character property lookup in l3regex eventually. None of that
code is in the svn yet.

What do you mean by converting one <integer> to a <balanced text>?
Could you give a couple of examples if you have time?

Sorry I didn't get back to you earlier: writing the ~4000 lines of
l3str+l3regex, plus some combined work with Joseph on xparse took me
most of the past 4 months.

Mapping Functions Versions for All and Some

dongen — 2012-02-02T10:29:58

Howsagoin,


I've started exploring the LaTeX3 sources documentation but
I couldn't find the equivalent of the following predicate
functions for token lists:

 o  \tl_all_TF:NNTF <token list> <predicate> <true> <false>
    results in <true> if all members of <token list> satisfy
    <predicate>. The semantics should be that the evaluation
    is start-to-finish of <token list> but that the evaluation
    is aborted as soon as one of the tokens in <token list>
    doesn't satisfy <predicate>.
 o  \tl_some_TF:NNTF <token list> <predicate> <true> <false>
    results in <true> if some member of <token list> satisfies
    <predicate>. The semantics should be that the evaluation
    is start-to-finish of <token list> but that the evaluation
    is aborted as soon as one of the tokens in <token list>
    satisfies <predicate>.

Similar versions may also be useful for other kinds of lists.

Are such macros defined? If not, do you think it's a good idea
to introduce them?

Regards,


Marc van Dongen

Unexpandability inside \csname

Will Robertson — 2012-01-29T12:56:50

Hello,

I've been away from LaTeX for a little while and now that I come back again I've almost immediately stumbled upon an area that I don't think I've fully understood previously.

Consider:

  \csname\ifnum 3 > 2 foo\fi\endcsname

This (probably obviously to all of you) complains with the standard "Missing \endcsname inserted." presumably because there's an unexpandable implicit \relax inserted somewhere in there.

In expl3 we've discussed the concept of "restricted expandability", which refers to an expandable function that doesn't fully expand inside an "f" function (which is expandable \romannumeral-style expansion).

Does it make sense to also indicate how/where expandable functions won't behave correctly inside "c" arguments? I must admit I haven't considered the ramifications of what these mean entirely. It does seem there's not necessarily much overlap between the f-unexpandable functions and the c-unexpandable ones.

Cheers,

LaTeX 2e here float processing

Frank Mittelbach — 2012-01-11T20:23:08

Hi

Because of the following question on TeX.sx:

http://tex.stackexchange.com/questions/39867/intextsep-gives-doubled-space/40363#40363

I looked into that bit of ancient code that typesets "here" floats and 
the more I look the more issues I find with it.

Basically right now if a "here" float succeeds it will more or less insert

\vskip \intextsep                            %% a)
\box <float>
\penalty \interlinepenalty                   %% b)
\vskip \intextsep                            %% c)
\ifnum\outputpenalty <-\< at >Mii  % float encountered in vmode
     \vskip -\parskip                         %% d)
\fi
\penalty 10000                % the original breakpoint modified by TeX

This has the following consequences:

  a) does not combine with a previous skip (as \addvspace would)

  b) provides a breakpoint after the float

  c) is not seen by any following \addvspace because of the penalty 
after it on the main vertical list

  d) cancels the upcoming \parskip that will be added by the next text 
line after the float.

-----------------

Now to make the \intextsep combine with surrounding vertical spaces one 
could use \addvspace at a) and would could ensure that the skip at c) 
actually comes after the \penalty 10000. That was my proposal to the 
question on TeX.sx

However, d) also becomes an issue if we have 2 "here" floats in a row. 
In that case there is no \parskip being added between the two floats 
thus we will end up with an extra \vskip -\parskip there --- which, if 
that has a positive value, will noticeably shorten the space between the 
two floats.

(as an aside: in the current solution we do get \vskip 2x\intextsep - 
\parskip here which isn't better but just bad on a different scale)

Now one possible solution that I could think of would be to add \parskip 
before the float (if in vertical mode) rather than subtracting it 
afterwards. That way it would be before and after and if several floats 
come in a row it would be between them (once) as well.
The downside of that would be that the spacing around floats would then 
change with a change to \parskip but that is something that happens in 
other places too within LaTeX and it would be somewhat consistent.

(not that I propose that as a general fix as that would break far too 
many documents)

------------------

But there is more which is not as it should (only the question being 
what should it be):

as the float is a box the distance from the top of that box to the 
baseline of the previous line of text depends on whether or not that 
line has a depth after all the \intextsep is just added after that line 
and no adjustment for the depth of that line is made. Thus the position 
of the float would depend on the characters in that last line.

Worse: the depth of the lin (stored in \prevdepth) survives until after 
the float is typeset (or even after any number of "here" floats are 
typeset) and will then be used to calculate the baselineskip for the 
first line of text after the float(s).

So if the text line before the float has chars with descenders (say a 
"g") then this will shorten the space from the bottom of the float to 
the following line -- cool.

Again one could think of schemes to resolve this, e.g., backup by 
\prevdepth before the float and then change it to zero so that it 
doesn't apply afterwards. However here I'm fare less sure if that is 
even ok in all cases: if the last line as some huge depth then this 
would mean that the float would even backed up into the previous object 
so I don't think that there is a good general solution here.

One could also argue for \nointerlineskip after the float then white 
space above and below would be the same.

Anybody any good thoughts what would be or could be an appropriate scheme?

frank

trial typesetting support

Frank Mittelbach — 2012-01-08T10:32:08

I just had a look into the following question on TeX.sx:

http://tex.stackexchange.com/questions/40330/centered-captions-containing-vref-may-not-always-appear-as-expected

The issue here is the following code:

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{#1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil\box\< at >tempboxa\hfil}%
   \fi
   \vskip\belowcaptionskip}


The problem is that this code trial typesets the caption as 
\sbox\< at >tempboxa{#1: #2} but then is not using it if the line is getting 
to long but instead uses  #1: #2\par. If however the line is short 
enough it reuses the box.

There are some reason for doing this (I mean not reusing the box in the 
multi-line version) as this has other deficiencies, but together with 
varioref this produces a problem. The problem being that varioref 
internally increments some counters to add label names and those are 
then never written to the aux file with bad results (basically a \vref 
may pick up the wrong information)

I wonder if this isn't a more general issue which needs addressing by 
providing some  "trial area" where you can go

\trial_start:
    ... do the trial
\trial_end:

where changes to counters dimensions etc are being stored away and 
returned back to their previous values afterwards.

what you would need then is a way to flag certain variables for this 
trial usage so that they can be properly saved and restored.

I think I remember that Michael Downes at one time wrote code for this 
for amsmath to manage labels and the like appearing in places like 
\mathchoice or in environments that do several trial typesettings to 
determine placement.

A brute force solution (but most certainly wrong with more complication 
structures in the caption) would be

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{\globaldefs=-1\relax #1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil #1: #2\hfil}%
   \fi
   \vskip\belowcaptionskip}

ie make all mods local in the trial and then retypeset the whole thing 
in both cases. But it is not difficult to see who this dies a different 
death depending on input.

Anybody some good ideas how to address topic this in a general fashion?

frank

trial typesetting support

Frank Mittelbach — 2012-01-08T10:32:08

I just had a look into the following question on TeX.sx:

http://tex.stackexchange.com/questions/40330/centered-captions-containing-vref-may-not-always-appear-as-expected

The issue here is the following code:

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{#1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil\box\< at >tempboxa\hfil}%
   \fi
   \vskip\belowcaptionskip}


The problem is that this code trial typesets the caption as 
\sbox\< at >tempboxa{#1: #2} but then is not using it if the line is getting 
to long but instead uses  #1: #2\par. If however the line is short 
enough it reuses the box.

There are some reason for doing this (I mean not reusing the box in the 
multi-line version) as this has other deficiencies, but together with 
varioref this produces a problem. The problem being that varioref 
internally increments some counters to add label names and those are 
then never written to the aux file with bad results (basically a \vref 
may pick up the wrong information)

I wonder if this isn't a more general issue which needs addressing by 
providing some  "trial area" where you can go

\trial_start:
    ... do the trial
\trial_end:

where changes to counters dimensions etc are being stored away and 
returned back to their previous values afterwards.

what you would need then is a way to flag certain variables for this 
trial usage so that they can be properly saved and restored.

I think I remember that Michael Downes at one time wrote code for this 
for amsmath to manage labels and the like appearing in places like 
\mathchoice or in environments that do several trial typesettings to 
determine placement.

A brute force solution (but most certainly wrong with more complication 
structures in the caption) would be

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{\globaldefs=-1\relax #1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil #1: #2\hfil}%
   \fi
   \vskip\belowcaptionskip}

ie make all mods local in the trial and then retypeset the whole thing 
in both cases. But it is not difficult to see who this dies a different 
death depending on input.

Anybody some good ideas how to address topic this in a general fashion?

frank

trial typesetting support

Frank Mittelbach — 2012-01-08T10:32:08

I just had a look into the following question on TeX.sx:

http://tex.stackexchange.com/questions/40330/centered-captions-containing-vref-may-not-always-appear-as-expected

The issue here is the following code:

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{#1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil\box\< at >tempboxa\hfil}%
   \fi
   \vskip\belowcaptionskip}


The problem is that this code trial typesets the caption as 
\sbox\< at >tempboxa{#1: #2} but then is not using it if the line is getting 
to long but instead uses  #1: #2\par. If however the line is short 
enough it reuses the box.

There are some reason for doing this (I mean not reusing the box in the 
multi-line version) as this has other deficiencies, but together with 
varioref this produces a problem. The problem being that varioref 
internally increments some counters to add label names and those are 
then never written to the aux file with bad results (basically a \vref 
may pick up the wrong information)

I wonder if this isn't a more general issue which needs addressing by 
providing some  "trial area" where you can go

\trial_start:
    ... do the trial
\trial_end:

where changes to counters dimensions etc are being stored away and 
returned back to their previous values afterwards.

what you would need then is a way to flag certain variables for this 
trial usage so that they can be properly saved and restored.

I think I remember that Michael Downes at one time wrote code for this 
for amsmath to manage labels and the like appearing in places like 
\mathchoice or in environments that do several trial typesettings to 
determine placement.

A brute force solution (but most certainly wrong with more complication 
structures in the caption) would be

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{\globaldefs=-1\relax #1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil #1: #2\hfil}%
   \fi
   \vskip\belowcaptionskip}

ie make all mods local in the trial and then retypeset the whole thing 
in both cases. But it is not difficult to see who this dies a different 
death depending on input.

Anybody some good ideas how to address topic this in a general fashion?

frank

How to describe category codes: documentation and \char_show_value_catcode:n

Joseph Wright — 2011-12-31T23:09:03

Hello all,

I was asked recently about the documentation of category codes in the
LaTeX3 docs. Currently, we say things like "category code 12 ('other')"
when describing what codes are active. We also provide
\char_show_value_catcode:n, which is just a wrapper around
\showthe\catcode. However, for setting catcode we use symbolic names,
for example \char_set_catcode_other:N.

While knowing catcode meanings is a required TeX programming skill, it
seems more in keeping with the LaTeX3 approach to talk about these by
their meaning. That raises two questions

 1) How should we refer to catcode in documentation, both in terms of
    the text and the formatting (for example, do we want to say
    something line 'category code <other>')?
 2) What should we do for \char_show_value_catcode:n? 'show_value' is
    not the right name for showing a symbolic meaning. I guess we just
    use \prg_case_int:nnn to actually show the meaning.

\leavevmode?

Ulrike Fischer — 2011-12-30T09:46:19

Hello,

what is the recommended way to issue a \leavevmode in latex3?

Active characters

Joseph Wright — 2011-12-27T23:14:27

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
\char_set_active:Npn.

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
\char_set_catcode_active:N).

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

Deprecated variable: \c_string_cctab

Joseph Wright — 2011-12-21T22:09:32

Hello all,

The LuaTeX-only variable \c_string_cctab has been renamed as
\c_str_cctab. The logic here is that all other 'string' cases in expl3
use 'str'.

The old version will be removed on or before 2012-03-31.
--
Joseph Wright

Documentation of local/global variants

Joseph Wright — 2011-12-03T09:34:24

Hello all,

Part of our recent efforts with LaTeX3 has been to improve the
documentation, adding in for example 'change dates' for functions in
l3kernel.

One area that I am not sure we have quite right at present is the
documentation of local/global variants. Where functions exist in both
local and global versions (for example \tl_set:Nn and \tl_gset:Nn),
there are currently separate documentation entries for the two cases.
This means that the scope of assignments can be clearly documented, but
does make for rather repetitive text.

A similar issue arises with the (TF) functions, where we have decided to
have a general statement about the nature of the two branches for the
entire content of interface3, and only to include information for
individual functions where a special case applies.

I wonder if it would make more sense to take the same approach for
functions with local/global versions. Something like:

'Where functions for variable manipulation can apply either locally or
globally, the latter case is indicated by the inclusion of a "g" in the
last part of the function name. Thus \tl_set:Nn is a local function but
\tl_gset:Nn acts globally. Functions of this type are always documented
together, and the scope of action may therefore be inferred from the
presence or absence of a "g".'

The scope would then be excluded from the function documentation:

% \begin{function}
%   {
%     \tl_set:Nn,  \tl_set:cn,
%     \tl_gset:Nn, \tl_gset:cn
%   }
%   \begin{syntax}
%     \cs{tl_set:Nn} \meta{tl~var} \Arg{tokens}
%   \end{syntax}
%   Sets \meta{tl~var} to contain \meta{tokens},
%   removing any previous content from the variable.
% \end{function}

Does this make sense as a sensible balance between formality and
documentation length?
--
Joseph Wright

rien ne va plus after TL-2011 package update

Alexander Grahn — 2011-11-15T14:15:37

Good afternoon,

I updated my TL-2011 packages today. Now, expl3 doesn't work anymore.

  \listfiles
  \documentclass{minimal}
  
  \usepackage{expl3}
  
  \begin{document}
  \ExplSyntaxOn
    \tl_new:Nn\g_example_tl{hello!}
    \g_example_tl
  \ExplSyntaxOff
  \end{document}

leads to:

  ! Undefined control sequence.
  l.8   \tl_new:Nn
                  \g_example_tl{hello!}
  ? q

What is going on?

Regards,
Alexander

 *File List*
 minimal.cls    2001/05/25 Standard LaTeX minimal class
   expl3.sty    2011/10/09 v2900 L3 Experimental code bundle wrapper
 l3names.sty    2011/10/09 v2896 L3 Experimental namespace for primitives
l3bootstrap.sty    2011/09/10 v2798 L3 Experimental bootstrap code
    etex.sty    1998/03/26 v2.0 eTeX basic definition package (PEB)
    calc.sty    2007/08/22 v4.3 Infix arithmetic (KKT,FJ)
   color.sty    2005/11/14 v1.0j Standard LaTeX Color (DPC)
   color.cfg    2007/01/18 v1.5 color configuration of teTeX/TeXLive
   dvips.def    1999/02/16 v3.0i Driver-dependant file (DPC,SPQR)
dvipsnam.def    1999/02/16 v3.0i Driver-dependant file (DPC,SPQR)
graphics.sty    2009/02/05 v1.0o Standard LaTeX Graphics (DPC,SPQR)
    trig.sty    1999/03/16 v1.09 sin cos tan (DPC)
graphics.cfg    2010/04/23 v1.9 graphics configuration of TeX Live
l3basics.sty    2011/10/09 v2896 L3 Experimental basic definitions
 l3expan.sty    2011/10/09 v2896 L3 Experimental argument expansion
    l3tl.sty    2011/09/16 v2831 L3 Experimental token lists
   l3seq.sty    2011/10/09 v2896 L3 Experimental sequences and stacks
   l3int.sty    2011/10/09 v2896 L3 Experimental integers
 l3quark.sty    2011/10/09 v2896 L3 Experimental quarks
   l3prg.sty    2011/10/09 v2896 L3 Experimental control structures
 l3clist.sty    2011/10/09 v2896 L3 Experimental comma separated lists
 l3token.sty    2011/10/09 v2896 L3 Experimental token manipulation
  l3prop.sty    2011/09/17 v2839 L3 Experimental property lists
   l3msg.sty    2011/10/09 v2896 L3 Experimental messages
    l3io.sty    2011/10/09 v2896 L3 Experimental input-output operations
  l3file.sty    2011/10/09 v2896 L3 Experimental file operations
  l3skip.sty    2011/10/09 v2896 L3 Experimental dimensions and skips
  l3keys.sty    2011/09/10 v2800 L3 Experimental key-value interfaces
    l3fp.sty    2011/09/26 v2857 L3 Experimental floating-point operations
   l3box.sty    2011/10/09 v2896 L3 Experimental boxes
l3coffins.sty    2011/09/12 v2814 L3 Experimental coffin code layer
 l3color.sty    2011/09/07 v2776 L3 Experimental colour support
l3luatex.sty    2011/09/10 v2798 L3 Experimental LuaTeX-specific functions
 ***********