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

[Dmitry Gutov]

On 10/11/2023 14:52, Po Lu wrote:
> (defun float-to-string (fnum &optional sci)
>    "Convert the floating point number to a decimal string.
> Optional second argument non-nil means use scientific notation."
>    (let* ((value (fabs fnum)) (sign (< (car fnum) 0))
>          (power 0) (result 0) (str "")
>          (temp 0) (pow10 _f1))
>
>      (if (f= fnum _f0)
>         "0"
>        (if (f>= value _f1)                   ; find largest power of 10 <= value
>           (progn                                ; value >= 1, power is positive
>             (while (f<= (setq temp (f* pow10 highest-power-of-10)) value)
>      .............
>        (if sign                         ; if negative, prepend minus sign
>           (concat "-" str)
>         str))))
>
> If it is to these that you apply the moniker "multi-line raw loop choo
> choo trains," then they are precisely what should be written more, not
> less.

I don't have the corresponding high-level implementation to compare to, 
but the main thing about the code you posted, is that one has to, 
basically, read every line (of which there are ~70) to understand what 
the function is doing and/or to find any irregularities in its 
implementation (e.g. when looking for a bug).

> The "Lisp way" (more felicitously the cl-lib way) is to provide
> functions to truckloads of other functions which interface them with one
> another.

A high-level approach is to use a set of agreed-upon abstractions 
(functional programming in general, across languages, has a basic set, 
but there can be additions) to write programs shorter.

> Each such function is a unique control construct.  To glean what a
> function does, one must not only commit each of these control constructs
> to memory, but as is all too often the case when the functions provided
> to the control constructs are beyond its control, also examine each of
> its callers, with labyrinths that put C++ to shame into the bargain,
> like pcase-lambda and macros which rewrite the control flow of a form
> beyond recognition.

There is, indeed, a mental cost to understanding the code which uses 
them -- one has to know the abstractions and be able to connect the 
names with the concepts. There aren't too many of them in use, though. 
We can argue whether cl-lib is an optimal set, or could be reduced 
(there are indeed many functions and macros in there that I never saw 
the point of using). But your proposed goal (full eventual removal of 
cl-lib, or anything like it) is a non-starter from my POV.