LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0 (Apple Message framework v929.2)
Content-Type:
text/plain; charset=US-ASCII; format=flowed; delsp=yes
Date:
Wed, 17 Dec 2008 17:02:34 +1030
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Will Robertson <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
7bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (83 lines)
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

ATOM RSS1 RSS2