Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
References: <AFA791BD-820C-4762-AF99-680B5A3DFA07@gmail.com>
            <4936E30A.5080209@morningstar2.co.uk>
            <87ljuxlybp.fsf@fawkes.hogwarts>
            <49370743.7050004@morningstar2.co.uk>
            <18745.37877.845526.230207@morse.mittelbach-online.de>
            <A9325DBA-A80E-4A6B-BE2B-B9FA4F005902@gmail.com>
            <18747.60665.106015.681211@morse.mittelbach-online.de>
            <944107A6-E45B-4F33-8F7B-AF98DC95AB54@gmail.com>
            <18748.52807.627728.138832@morse.mittelbach-online.de>
Message-ID:  <2AA8A307-5ADE-4852-9DF3-42BCC71F238A@gmail.com>
Date:         Wed, 17 Dec 2008 17:02:34 +1030
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: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: expl3 "token list" terminology
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <18748.52807.627728.138832@morse.mittelbach-online.de>
Precedence: list
Status: R

On 08/12/2008, at 6:05 PM, Frank Mittelbach wrote:

> Will Robertson writes:
>> On 08/12/2008, at 2:04 AM, Frank Mittelbach wrote:
>>>
>>> well you got me thinking on that level, because tlp could be named
>>> tlist to fit with plist clist.
>>>
>>> the problem seems to be more in the later addition of the \tlist
>>> functions
>>> that in contrast to anything else do not operate on some storage
>>> bins but on
>>> tokens in the input stream.
>>
>> Hmmm, I agree tlist would be nice and consistent; after all we don't
>> have "clist pointers" and "plist pointers". But then what would we
>> rename what are currently tlists?
>
> that's the problem. It is something like \tlstream or \tstream  
> (operating on
> an input stream of token (list)), but I'm not sure this makes it  
> better (only
> longer)
>
> Another point to consider is that _tlp is the predominant storage  
> bin used
> all over the place, so something snappy might be preferable over  
> something
> longer (such as _tlist)

An immodest proposal:

Change all \tlp_ functions to \tlist_ , leave all \tlist_ functions as  
they are, and let the argument specification clarify whether we're  
dealing with a token list or a token list pointer. There are no  
clashes in the function names (as far as I can see).

This has precedence, for example, with
    \clist_map_inline:Nn
    \clist_map_inline:cn
    \clist_map_inline:nn

My only doubt is that \tlp_ is "more snappy". But changing \tlist_ to  
\tlp_ clearly doesn't work.

For suffixes, I actually think that _tlp works fine, since it doesn't  
need to be the same as the module name (e.g., see \prop_ and _plist).  
But I do think the naming of the modules and their data types could  
use some re-evaluation.

We currently have:

MODULE       DATATYPE    PREFERRED
\clist_      _clist      * (no better options?)
\seq_        _seq        * (snappy)
\toks_       _toks       * (snappy)
\prop_       _plist        (inconsistent module/datatype names vs. the  
above)
\tlp_        _tlp          (problem with tlp vs. tlist)

I'm proposing changing #5 above to:

\tlist_      _tlp        * (inconsistent module/datatype, but snappy  
at least)

Here are some other options of changes that could be made:

\tlist_      _tlist
\tlist_      _tl
\clist_      _clp
\prop_       _prop       * (_prop is shorter and I think has more  
meaning)
\plist_      _plist
\plist_      _plp

What do you say? I'm uncomfortable with having separate modules for  
\tlp_ and \tlist_ at the moment, and we could change _plist to _prop  
at the same time. I don't think we should change this right now, but  
(depending what the comments are here) I'll write it up as a major  
"todo" once the test suite is ready.

Will