MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <48C3DAD1.6030004@morningstar2.co.uk>
            <4B6A6CEE-A06F-4EAC-B618-3B637A5902E4@gmail.com>
            <18630.50165.621679.420173@morse.mittelbach-online.de>
            <20B59161-A27F-4FE5-98E5-0FB3F051073B@gmail.com>
Message-ID:  <18631.42022.160484.847483@morse.mittelbach-online.de>
Date:         Wed, 10 Sep 2008 12:40:38 +0200
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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: expl3 variant expansion forms
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <20B59161-A27F-4FE5-98E5-0FB3F051073B@gmail.com>
Precedence: list
Status: R

Hi Will,

 > 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.

obviously impossible is perhaps too strong a word, but I wouldn't consider it
a good use of time to devise a robust self-extending system using TeX as the
underlying formatter. As i said earlier you can do careful parsing at
definition time identifying which functions are undefined and define
them. That would slow down definition parsing but not runtime, proving a
robust and probably fast system in the end.

see other mail for a way to do it quick and dirty at the cost of speed and
robustness


 > > 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.

to some extend

 > 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.

Some uniformity is certainly helpful, but I don't believe that Joseph was
confused (only a bit surprised) but leaving that aside :-) ...

 > 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.

uniformity within a module is most certain good but already between modules is
questionable in my opinion.

for example, while tlp and toks probably need access equally from both sides
this is questionable for clists (imho). so just providing the base function
rather than 10 variants on top for the _left case here isn't something I would
feel too bad about. (on the other hand, if we settle for a "small" set of
uniform variants that we always provide and take out all others and move them
to the xpackages that actually use them, certainly has its merrits)

or take sequences which perhaps shouldn't have _left/_right at all but perhaps
only

   push pop top append (not existing)

making the intention of "sequencing" and "stacking" clearer. (okay, that
really a different discussion)


 > 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.

trim down is not so easy than trimming up which is why i would go for less
than for more.  I do agree with you that at this stage, some uniformity will
help and that what you proposed, ie

   :Nn
   :No
   :Nx
   :cn
   :co

on all and removal of all others to the xpackages that use them sounds
reasonable to me. It was probably a mistake to add functions to the core just
because one package needed them (we can do that later if more packages show
which kind of variants are really commonly needed).

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

my initial mail was not a reply to the specific proposal but about the danger
of going overboard with providing all kind of variants

cheers
frank