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

[Po Lu]

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

> What the heck?  What I said, is that if Elisp _had_ better
> ways of making compartments, such as namespaces, managing which
> compartments are preferred in certain parts of code would be easier.
> I stated multiple times that I tend to trust developers to pick
> the tools they find most appropriate for the job.  I simply stated
> that it's funny and ironic that the language whose influence you're
> trying to exorcize is precisely the one with one of the best
> tools to do that exorcizing.

Which is tantamount to, or at least comes off as, arguing in favor of
that language's influence.

> Maybe you didn't understand this because you're not familiar with
> CL packages, so I can explain.  In CL you can actually write a program
> in a package that doesn't ':USE' the :COMMON-LISP package at all, or
> that only imports a handful of symbols from it (maybe the sacred
> Elisp subset).  Or you can make your own packages with just the
> symbols you want and maybe use that.  Meaning you'd be effectively
> insulated from CL or at least the parts you don't like and could
> write your perfect purist Lisp program.   Come on, isn't that funny?

I know how packages function under Common Lisp, but they are not
salvation.  My objective is not to write code free of Common Lisp
influence; this I already do.  It is for everyone else to write them, or
provide a 95% effective guarantee that I (and many others) will never
have to read them, which is easier said than done; a leitmotif in Emacs
development is for active developers to vanish overnight, leaving a
small corps of developers with reponsibility for their upkeep in the
years that follow.

Granted, the foregoing is something of an overstatement.  But the
alacrity with which programmers seize at opportunities to employ cl-lib
does call for one.

> There are no "beliefs" in Common Lisp's, neither should there be
> in Elisp.  I don't think it helps your case to repeatedly evoke
> religion.

Really?  Here is one example to the contrary: keyword arguments.  No
Emacs Lisp built-in takes them, yet it is scarcely possible to name a
Common Lisp list manipulation function that does not.

> Every other choice also has "implications".  Most people favourable
> to cl-lib in this discussion know why they chose to use its functions.
> I wouldn't be so condescending.

Yet few of these people consider the impact their decision makes to
others, who will in due course have the responsibility for reading this
code pawned off them.

> 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)

> and
>
>    ;; iterate through someseq and find index of first element
>    ;; whose car matches probe according to 'probe-equals'.
>    (cl-position probe someseq :key #'car :test #'probe-equals)
>
> Shouldn't take long.  I can try myself, of course, but I think it's
> fair to give the proponent of the alternate approach a shot before
> comparing the two approaches.

(catch 'tag
  (let ((index 0))
    (dolist (tem someseq)
      (when (eq (car tem) probe)
        (throw 'tag index))
      (setq index (1+ index)))))

> Some get confused by cl-labels, some by archaic things like rplaca,
> some by new stuff like static-if.  Doesn't matter what is alias to
> what, when you see both these things  in code you don't know what
> they do until you look them up.  And many times you'll think "there's
> a much better way".

There's not much of a point in arguing against such patent absurdities
as considering the operation of setcar as complex as that of cl-labels,
is there?

> OK.  So, basically, your code :-) '(if x (progn ...))' instead
> of 'cond', and lots of handrolled catch/throw with while t. OK fine.
>
> I have a feeling I think you'd love cl-loop, maybe even too much :-)

I think not.

> Also quite some long functions there.  300 lines? Maybe typing
> "touch-screen" each time to define and call functions
> discourages you from modularizing more?  Or maybe it doesn't
> bother you at all, so fine.

It doesn't bother me that functions for whom there are no reasons to use
their constituents elsewhere have yet to be balkanized, no.