Re: What's missing in ELisp that makes people want to use cl-lib?

[Po Lu <luangruo@yahoo.com>]

João Távora <joaotavora@gmail.com> writes:

> But that leitmotif is everywhere (and us much less strong in open-source,
> btw).  Surely if you've ever worked at a large enough company you'll see
> bizarre code from people not working there anymore.

Where I work, our practices and policies prevent these difficulties from
ever materializing.  Think a standardized coding style, mandatory quotas
for documentation length, expositions written and, hmm, anthologized
independently of the code itself, and review by individuals who have,
needless to say, never seen the code before in their lives, and will not
so much as bat an eyelid before striking down code they cannot easily
understand.  The first and third are what's being proposed here for
Emacs, unless I'm greatly mistaken.

> And that goes for everything.  You think everyone will forever be
> grateful to read your 300-line inline-all-the-things functions in
> touch-screen.el when you're not around to explain what they do?  They
> won't.

It's well-documented and in line with other Emacs Lisp code, so I think
they will.  Indeed one individual is already implementing the
recognition of panning and zoom gestures with it as a basis, without any
counsel from me besides referring him to the file itself.

> It makes no sense to single out any given library for this evil,
> especially not cl-lib.el which is a well-understood stable piece of
> kit.  In Emacs core and just as strongly outside it.

See what I explained earlier.

> Many examples of Emacs Lisp functions take them.

Like?  Which list manipulation functions do?
Contrast cl-member to member.

> Even Richard seems to have come around to their usefulness.  CL
> functions take them in consistent ways, but you can use them without
> keyword arguments if you're stubborn enough.  Anyway, it's not a
> "belief", it's just a good way to provide versatility for functions.

A "belief" in this sense is a model or general scheme that is adhered to
when designing a function, of course, so let's not descend into
quibbling.

> Why do you exempt yourself from this irresponsibility?  Can't you see
> this is all subjective and it seems a bit arrogant to say "my code is
> so responsible"??

Thus far there have been no complaints that code _without_ cl-lib,
pcase, seq or elt is unreadable.  Most of our code (this time measured
by lines) falls squarely within that category.

> All code is bad.

With that outlook, there's not much of a purpose in writing any code for
Emacs, is there?

>> > Hmmm, a bit vague, no?  Humor me: if it's really so easy and so
>> > readable please write out your preferred equivalent of, say
>> >
>> >    (cl-set-difference l1 l2) ; hopefully obvious, like l1 - l2 in python
>>
>> (let ((list nil))
>>   (dolist (x l1)
>>     (unless (member x l2)
>>       (push x list)))
>>   (dolist (x l2)
>>     (unless (member x l1)
>>       (push x list)))
>>   list)
>
>>
>> (catch 'tag
>>   (let ((index 0))
>>     (dolist (tem someseq)
>>       (when (eq (car tem) probe)
>>         (throw 'tag index))
>>       (setq index (1+ index)))))
>
> Nuff said :-)  .  So if multiple set difference operations or multiple
> index-finding operations are needed you write these choo-choo trains
> again and again.  That sure explains the 300 lines.

Sure, but catch, let, dolist, when, throw, setq and member are
elementary operations under Emacs Lisp everyone learns.  They are also
few in number.

> I guess not for human versions of --finline-functions who think, or
> rather "believe" that such common practices for code reuse as
> subroutine encapsulation is "balkanization".  It's probably "patently
> absurd" for them yes.

But the Emacs Lisp compiler doesn't inline functions, does it?  At any
rate you have conflated one of my statements with the other, so read
again.

Thanks.