LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sun, 7 Dec 2008 19:28:19 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (168 lines)
Will Robertson writes:
 > On 06/12/2008, at 9:43 AM, Joseph Wright wrote:
 > 
 > > BTW, I'd missed
 > > the point that "\exp_args: ...  not to be used within the code": I'll
 > > have to revisit some of my ideas.
 > 
 > Maybe we need some more programming tools that do similar things,  
 > then. (I've been tempted to use things like \exp_args:NNO instead of  
 > chains of \exp_after:NN.)
 > 
 > I guess we could do something like this...?
 > 
 >    \let_new:NN \exp_after:NNN  \exp_args:NNO
 >    \let_new:NN \exp_after:NNNN \exp_args:NNNO

I don't think this going to work, in my eyes this is mixing up two different
concepts (which is what we already incorrectly did with \exp_after:NN as a name)

 - the expl3 idea to to have base variants of functions and argument
   manipulation prior to calling the base function

 - the manipulation that \expandafter is doing

so yes, \exp_after:NN is named somewhat incorrectly it would probably
better simply named \exp_after:D or \exp_after:w but the main point is that

   \exp_after:NN

is not really the same as

   \exp_args:NO

The problem is that N in all such exp_args functions denotes a single token
but only tokens that can appear as arguments and that means not something like
and open or closing brace.

That in turn means that

 > Where:
 >    \def_long_new:Npn \exp_args:NNO #1#2#3 {
 >      \exp_after:NN #1 \exp_after:NN #2 #3
 >    }
 > 
 > Both have the naming problems of \exp_after:NN itself, where they can  
 > be used to expand past a brace in a situation like
 > 
 >     \exp_after:NNNN \foo \bar { \baz }
 > -> \exp_after:NN \foo \exp_after:NN \bar \exp_after:NN { \baz }

is not going to work. 

As you follow up you would therefore need something like

 > So they should probably be
 > 
 >    \exp_after:wN
 >    \exp_after:NwN
 >    \exp_after:NNwN

with the "w" denoting the place where a { could appear, but I have my doubts
that such functions improve readability that much, eg

   \exp_after:NNwN \foo \bar { \baz }

some problems with that approach:

 - how do i know what is being expanded? (always the last token?) - here it is
   actually the second last token in the line so i need to count and match. I
   guess that would

     - need a special module (maybe \exp_tokens:...)
     - a notation that clearly indicates where braces are possible
     - a notation that shows which token is expanded 

perhaps Morten is right and we need something to denote that we expand a token
and not surounding it with braces afterwards, However, that all goes back to
rationalizing the notation in the first place, and I would suggest to table
that idea and reconsider it with the bigger topic of <arg-spec> syntax cleanup


 > 
 > * * *
 > 
 > I know the idea of expl3 is to move away from these sorts of things,  
 > but I think that the \expandafter functionality is pretty unavoidable  
 > in some circumstances; consider:

yes and yes, expl3 is really a paradigm shift to ban wild expansion and
confine it to internal low-level definitions (such as \toks_use_clear:N) but
something like \exp_after:NN should be seldom if ever necessary if work on
higher-level modules. Especially chain expansion that you want to tackle with
this approach should not happening in such higher-level modules
 > 
 > \def_new:Npn \toks_use_clear:N #1 {
 >    \exp_after:NN
 >      \toks_clear:N
 >    \exp_after:NN
 >      #1
 >      \toks_use:N#1
 > }
 > 
 > which could be written simply as
 > 
 > \def_new:Npn \toks_use_clear:N #1 {
 >    \exp_after:NwN \toks_clear:N #1 \toks_use:N #1
 > }
 > 

yes, simpler granted, but is it worth the extra processing (arg reading and
expansion rather than direct primitive TeX expansion) and is it needed
anywhere outside those low-level modules defining new data structures and
their processing? I have my doubts.

 > * * *
 > 
 > Open questions:
 > 
 >   - is "exp_after" the best name, still?
 >     "exp_last" ?
 >     \exp_ii:wN / \exp_iii:NwN / \exp_iv:NNwN ? (I like this; see below)

maybe, I agree the current name (though dear these days :-) is wrong

 > 
 >   - can these be nested/threaded/whatever-the-word for simplifying  
 > situations like
 >       \@xa\@xa\@xa\foo\@xa\bar\baz ?
 > 
 >        \exp_after:NNwN \exp_after:wN \foo \bar \baz
 >     or \exp_iv:NNwN \exp_ii:wN \foo \bar \baz
 > 
 >     Seems okay.

well, I guess it will work but it doesn't seem to me getting more readable
than the other. more importanly in nearly all cases where we have a complicated
expansion it is not expanding the input stream but preparing argument
expansions, in other words, it should be handled in expl3 by a base function
and then use a variant.

 >     Could then write
 > 
 >       \def:Npn \exp_iii_ii:NNN { \exp_after:NNwN \exp_after:wN }
 >       \exp_iii_ii:NNN \foo \bar \baz
 > 
 >     Seems nice, and fits in with the nomenclature of \use_ to an extent.

that's true.


 > * * *
 > 
 > Thoughts? There is definite overlap between these functions and what  
 > the \exp_args functions do, but I think there's enough justification  
 > to include functions like this, carefully, into l3expan.

well, I think that whole topic should get further attention and eventually a
decision. I personally think that the inline expansions are something
completely different from  the arg expansion module which is to prepare for
the variant concept.

we may want to have something like the above eventually (then again perhaps
not) but i think we should first understand how we want to rationalize the
<arg-spec> as whatever we do or not do there has an influence on how this
here should look like

frank

ATOM RSS1 RSS2