MIME-version: 1.0
Content-type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: 7bit
References: <55DBB7F6.1070307@clear.net.nz>
            <55DABA1D.3050706@morningstar2.co.uk>
            <55DCFDF7.7080305@clear.net.nz>
            <55DC05BF.1040505@morningstar2.co.uk>
            <55DC28E8.9090405@morningstar2.co.uk>
            <55DDFD0A.4000901@clear.net.nz>
            <CANQYN6wzPW4aeO0WftqthfZ_6szd6-E60OzGhZcZ1g6JM6rseg@mail.gmail.com> <55DDACCB.1070104@morningstar2.co.uk>
            <55DF523F.2050905@clear.net.nz>
            <CANQYN6zrXjg70uJaw4dEd+_Adye0KHU90dYVmRqpR8CpiOp0_g@mail.gmail.com> <55DF48BE.5030503@residenset.net>
            <55DF5276.7010500@morningstar2.co.uk>
            <55DF70B2.1090700@morningstar2.co.uk>
            <55E09AA8.6070100@residenset.net>
            <CANQYN6xAa8TX+p6kvAKk+dvNjMneL9=PhGQebcvDa+P3izkVUg@mail.gmail.com> <55E176DB.6000109@clear.net.nz>
            <87bndq2yr6.fsf@fencepost.gnu.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
            Thunderbird/38.0.1
Message-ID:  <55E2188B.2050209@clear.net.nz>
Date:         Sun, 30 Aug 2015 08:39:39 +1200
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: aparsloe <aparsloe@CLEAR.NET.NZ>
Subject: Re: Catcode changes
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <87bndq2yr6.fsf@fencepost.gnu.org>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 29/08/2015 10:08 p.m., David Kastrup wrote:
> aparsloe <aparsloe@CLEAR.NET.NZ> 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