emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 7 logical-xor implementations in source tree


From: Basil L. Contovounesios
Subject: Re: 7 logical-xor implementations in source tree
Date: Thu, 01 Aug 2019 03:09:04 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Drew Adams <address@hidden> writes:

>> > Why is it important that Emacs Lisp have such
>> > an operator?  (Answer: it's not - YAGNI.)
>> 
>> If YAGNI, why are there currently 7 copies of this function in the
>> Emacs sources?
>
> Dunno.  I probably wouldn't have added them.

Then we're not talking about the same Y in YAGNI. ;)

> OK, so we have 7 definitions of a trivial function.
> How many occurrences of those 7 functions?

You can see all 17 in-tree occurrences in the patch(es) proposed
elsewhere in this thread.  There exist also further copies and
occurrences in some GNU ELPA and MELPA packages.

> Do their uses really benefit from defining such a function?

I think they allow the relevant code to remain more succinct and clear.

> (How about just replacing all of them by sexps?)

I invite you to try it, but I don't expect the diff or result to be that
pretty, especially not in idlwave.el.

>> No-one said it's vitally important; it's just a minor nice-to-have.
>
> Just 1 opinion: too minor and not nice enough to have.

I think the OP, as well as most follow-ups in this thread, indicate the
opposite.

>> > Is it hard to understand (eq (not a) (not b))?
>> > Is evaluation of that inefficient?  Is it too
>> > verbose?  What's the motivation for all of this?
>> 
>> Same reason proper-list-p was added: reducing existing code duplication
>> and providing yet another convenience function for those that like it.
>
> I see.  You added `proper-list-p' also.  Also missing
> from Common Lisp, FWIW.
>
> How much real code duplication did adding that predicate
> eliminate?  At least in that case the code replaced is,
> even if straightforward and not very verbose, not
> completely trivial.
>
> I don't object strongly to adding such functions.
> But I'd expect a convenience function to typically be
> more convenient - replace more than a few occurrences
> of more complex code.

The point is not just eliminating existing duplication, but also
providing a named convenience function for future use (both naming and
convenience are useful in general).  You may not see the utility in this
case (which is perfectly understandable) but it is clear to me that
several others do.  (See also the recent discussion on decoded time
accessors.)

Thanks,

-- 
Basil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]