GNU bug report logs - #34852
26.1; seq-intersection ignores nil as element

Previous Next

Full log

Message #98 received at 34852 <at> debbugs.gnu.org (full text, mbox):

From: "Miguel V. S. Frasson" <mvsfrasson <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
 Nicolas Petton <nicolas <at> petton.fr>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 34852 <at> debbugs.gnu.org
Subject: Re: bug#34852: 26.1; seq-intersection ignores nil as element
Date: Sat, 16 Mar 2019 17:33:10 -0300

Hi

Maybe this is the same bug, now with seq-difference

(seq-difference '(nil) '(1 nil) #'eq)
-> (nil)

(In my applications, nil is a frequent element of my lists)

Is this fixed by the proposed patches?


Cheers.

Miguel

Em sex, 15 de mar de 2019 às 13:08, Miguel V. S. Frasson
<mvsfrasson <at> gmail.com> escreveu:
>
> Hi
>
> I was convinced by the discussions here that changing seq-contains is a bad idea.
>
> I had the false premise that ELT=nil makes seq-contains return nil.
>
> If I could make a suggestion, it would be include an &optional NOT-FOUND to be the value returned in case of not finding any element matching TESTFN.
>
> Cheers
>
> Miguel
>
> Em sex, 15 de mar de 2019 12:56, Basil L. Contovounesios <contovob <at> tcd.ie> escreveu:
>>
>> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>>
>> > "Miguel V. S. Frasson" <mvsfrasson <at> gmail.com> writes:
>> >
>> >> In any case, of another implementation for seq-intersection or not, I
>> >> think that the solution from Stefan should be implemented anyway
>> >> because
>> >>
>> >> * it makes seq-contains provide a useful return value when ELT=nil, so
>> >> it is a good exception; If ELT=nil, seq-contains currently returns nil
>> >> anyway;
>> >>
>> >> * it makes seq-contains become a real predicate function, making it
>> >> more useful;
>> >>
>> >> * since seq-contains has been used as predicate before, it is
>> >> unpredictable which code uses it out of official repositories, so this
>> >> fix potentially fixes other code.
>> >
>> > BTW, another (alternative) alternative would be to make it return
>> > (list ELT).  That would be a bit less backward-compatible, but a
>> > bit more consistent.
>>
>> +1, either this or returning a boolean is fine with me.
>>
>> --
>> Basil



-- 
Miguel Vinicius Santini Frasson
mvsfrasson <at> gmail.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.