1.0 (Apple Message framework v928.1)
text/plain; charset=US-ASCII; format=flowed; delsp=yes
Wed, 10 Sep 2008 10:45:10 +0930
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
Recall again that we're talking about functions like
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
So I was probably a little unclear about my intentions for that code.
Does my reasoning make sense, in the end?