Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
References: <48C3DAD1.6030004@morningstar2.co.uk>
            <4B6A6CEE-A06F-4EAC-B618-3B637A5902E4@gmail.com>
            <18630.50165.621679.420173@morse.mittelbach-online.de>
Message-ID:  <20B59161-A27F-4FE5-98E5-0FB3F051073B@gmail.com>
Date:         Wed, 10 Sep 2008 10:45:10 +0930
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 variant expansion forms
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <18630.50165.621679.420173@morse.mittelbach-online.de>
Precedence: list
Status: R

Hi Frank,

Thanks for the detailed comments.
When I first read about expl3 years ago, indeed I was naively  
disappointed that the variants weren't constructed "on the fly". But  
that's obviously impossible.

***

> So rather than providing everyting for the sake of uniformity I  
> would suggest
> to allow for gaps (as they can be very very easily filled ... for any
> developer who understood the construction method).

I do agree that we don't want to define *most* variants up-front  
(especially at this early stage), but I think the case involving  
put_left/put_right is a little bit different.

The idea here wasn't to provide the variants "just because", but  
rather to not confuse the programmer by defining, for example, (as  
Joseph pointed out) put_right:Nx and *not* gput_right:Nx. While we  
can't be uniform across the board with providing every expansion  
variant, I do think we should be uniform amongst commands that are so  
similar.

Recall again that we're talking about functions like
   clist_put_left
     seq_put_left
     tlp_put_left
    toks_put_left
so it seems crazy (IMHO!!) not to define *them* uniformly.

Now, in the code I posted to the repository I went somewhat overboard,  
because I erred on the side of adding consistency but without taking  
anything out (or considering special cases). Since there was an  
instance of the not-generally useful :Nc and :NC variants for two of  
the functions, I defined that variant for them all. With the thought  
that it's always easy to trim down the list after discussing things  
over here.

So I was probably a little unclear about my intentions for that code.   
Does my reasoning make sense, in the end?

Thanks again,
Will