LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

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: Sun, 30 Aug 2015 08:39:39 +1200
MIME-version: 1.0
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Content-type: text/plain; charset=windows-1252; format=flowed
From: aparsloe <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Message-ID: <[log in to unmask]>
Content-transfer-encoding: 7bit
Parts/Attachments: text/plain (64 lines)
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

ATOM RSS1 RSS2