On 29/08/2015 10:08 p.m., David Kastrup wrote: > aparsloe <[log in to unmask]> writes: > >> On 29/08/2015 9:26 a.m., Bruno Le Floch wrote: >>> Joseph understood your point perfectly well. Xparse takes care of >>> matching nested parentheses, and does that expandably too. It would >>> be possible for Andrew to abuse xparse to grab his parenthesized >>> group, but I am not sure whether I want to advise this or not. It >>> would also be possible to simply copy the code, but finding out >>> where this is done in xparse's code is non-trivial. I could also >>> just provide code that does that, but it would take 30 minutes to >>> get completely right and clean (the code needs to carefully preserve >>> braces when grabbing delimited arguments, for instance). Using >>> \tl_set_rescan:Nnn seems reasonable given the above. >>> Bruno >> The suggestion that the documentation note the use of empty setups for >> \tl_set_rescan:Nnn seems to have sparked a wider discussion (much of >> it beyond me, but interesting as a spectator). The final area where >> I've used rescanning is in parsing nested commas for functions of >> multiple arguments. l3fp has max and min. It is easy to translate an >> expression involving possibly nested \max and \min to a form that l3fp >> can digest. All the hard parsing work is conducted out of sight in >> l3fp. But there are other functions, like greatest common divisor, >> \gcd, which have no corresponding l3fp member. To handle an expression >> like \gcd(15,24,33) I equate a comma list to the argument 15,24,33 >> then pop the items of the comma list into token list variables which >> can be converted to integers and fed to the gcd algorithm. But for a >> nested expression like >> >> \gcd(\max(7+\max(5,2),8),\min(24,29),10+5,\gcd(30,45,6)) >> >> the argument of the outer \gcd can't be equated to a comma list >> without mangling the mathematical syntax. I've treated this by >> rescanning ( and ) to group begin and end in the argument token list, >> then equating a comma list to the rescanned argument. The individual >> items of the comma list are now the correct ones. The token lists >> resulting on popping items from the comma list are then rescanned with >> an empty setup to get everything back to "normal", converted to >> integers and fed to the gcd algorithm. >> >> To me the way rescanning cuts through the complexity makes it seem (as >> they say in medicine of an effective drug) like a magic bullet. > At one point of time I wrote some stuff in order to read the Lisp-like > PL files written by tfm2pl. To avoid any O(n^2) behavior, the bulk of > the reading was done in one large \edef where ( had active character > syntax and ) had group closing syntax if I remember correctly. Maybe > some of the trickery used in \lispdef and friends might be > inspirational, so I'll just append the code here. Mind: this is not > production code and I don't think I ever got to using it or anything. > But it did accomplish the parsing. > > Maybe it does not actually help since you _have_ to set up weird > catcodes before starting and that may be not compatible with your > requirements. > Thank you David. It is always helpful (and perhaps a little daunting) to see what others have done. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus