User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2)
            Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
References: <4E692829.2000003@morningstar2.co.uk>
            <CAArVCkRdSyDDjKjS=yXrMZ+h+Pr0OQFJ1ZrW-Hdh3j-687QPKw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E75B860.40106@morningstar2.co.uk>
Date:         Sun, 18 Sep 2011 10:22:40 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Removal of previously-notified functions
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <CAArVCkRdSyDDjKjS=yXrMZ+h+Pr0OQFJ1ZrW-Hdh3j-687QPKw@mail.gmail.com>
Precedence: list
Status: R

On 18/09/2011 09:50, Philipp Stephani wrote:
> It's probably too late, 

I'd hope we are a long way from 'too late'! It's clear that we will
continue to adjust expl3 as issues arise, and it seems pretty clear that
the team are willing to look again at issues as they arise.

> but I'm quite sure that the removal of
> \tl_new:Nn, \ior_new:N and \iow_new:N should be reverted. It is
> universally considered good style to combine declaration and
> initialization of variables, and having two different commands for
> declaration and setting leads to awkward duplication. 

Part of the reasoning we had here is that \tl_new:Nn was being used
almost entirely for declaring constants. We have a conceptually-separate
\tl_const:Nn for that job.

The other part to the reasoning was that while we had \tl_new:Nn, we did
not have \int_new:Nn, etc. So we were not exactly consistent in that
regard. I guess based on the underlying TeX concept that registers have
to be allocated separately to assignment, it seemed easier to take a
similar approach to everything. (I also note that we'd have issues with,
for example, property lists as they can't really be created and
fully-assigned in one shot, at least through anything like the
documented interface.)

> Regarding
> \io[rw]_new, without them it is is impossible to check for overwriting
> of stream names. Just like with all other variable types, these should
> be declared before usage.

This is a slightly different issue, as streams are not exactly
variables. In the current implementation, streams are undefined when
they are closed, as once TeX closes a write stream we can't simple
re-open it. We could I guess check for an existing file, read the entire
thing to memory, then re-write it and then append. On the other hand,
perhaps this would be overkill and simply overwriting would be the
correct response. With a read stream, I guess we'd need to worry about
whether you'd store the position in the file, so that you'd re-start
from the same line. Again, this might be overkill. I guess an
alternative is to set up the code such that a stream which has been
closed will give a suitable error message if one tries to use it.

> Also a \cs_new:N command is missing which reserves a "function" name
> without assigning it. Both \io[rw]_new:N and \cs_new:N can essentially
> be aliases for \chk_if_free_cs.

Well, they can't simply be \chk_if_free... as there has to be a
'reserve' stage too. With \cs_new:N, the problem was that you don't know
how many arguments there may be, or in what form they could be. So you'd
at the least need \cs_new:Np, and then have to work out how to delimit
the end of the primitive argument specification. That's before you worry
about long and protected status (which apart from a small number of
tmp:w functions should not vary). So for functions I'm not sure I see a
gain over \cs_new(_protected)(_nopar):N(p)n.
-- 
Joseph Wright