My experience of dealing with language design for 'operators that get extended from binary (infix) to what computing people call 'nary' or 'nary' (NOT the meaning I used for this as a mathematician) is that it is best to define a distinct operator that acts on a sequence (or list if you want potential unboundedness).
I am unsure whether it is relevant here to point out that this idea has a long mathematical pedigree in the use of 'summationsigma' for repeated addition over
a finite but arbitrary sequence.
This would give Arno's:
or possibly something more explitly a sequence/list inside.
\bool_and_p:n {\bool1,...,\booln}
But I would never wish to deprive others of complex infix operator expressions (even nonassociative and noncommutative ones if they insist) After all, we inflict them on our kids from the very beginning. Who knows, our gene pool may be specially adapted to make us love them:).
chris
Arno Trautmann <[log in to unmask]> wrote: 
To: [log in to unmask]
From: Arno Trautmann <[log in to unmask]>
Date: 21/09/2010 06:32
Subject: Re: boolean expressions in ExplSyntaxNames
Will Robertson wrote:
> On 21/09/2010, at 2:50 PM, Arno Trautmann wrote:
>
>> Will Robertson wrote:
>>> On 20/09/2010, at 11:27 PM, Frank Mittelbach wrote:
>>>
>>>> is there actually any need for the :nnn etc versions?
>>>
>>> Not sure, is there?
>>> They seem natural to me; better than nesting multiple :nn commands for more than two ‘and’ branches, say.
>>
>> But then you’re lost at five ”and“. What about, say
>> \bool_and_p:n {\bool1,...,\booln}
>> i.e. a list of boolean expressions? (Just for the interface, no idea how
>> to implement this in an efficient way)
>
> Why not just use && in the first place?
Because of possible catcodetroubles? ;)
Or maybe such a list might be more useful for a xor operation.
cheers
Arno
[attachment "signature.asc" removed by Chris Rowley/mcs/UK]

The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302)
