LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Sat, 29 Aug 2015 12:08:13 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
In-Reply-To: <[log in to unmask]> ([log in to unmask] message of "Sat, 29 Aug 2015 21:09:47 +1200")
Content-Type: multipart/mixed; boundary="=-=-="
From: David Kastrup <[log in to unmask]>
Parts/Attachments: text/plain (2982 bytes) , forvir.doc (46 kB) , text/plain (46 kB)
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

-- David Kastrup