Re: [PATCH] Add cl-map-into

[akater]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> - Could you provide some corresponding tests for test/emacs-lisp/cl-tests.el?

There are some tests in comments; I'll make them into proper tests and
add some more.

>     (cl--generic-with-memoization
>         (if small
>             (aref cl--map-into-mappers-array sig)
>           ;; TODO: Order alist entries for faster lookup
>           ;; (note that we'll have to abandon alist-get then).
>           (alist-get sig cl--map-into-mappers-alist nil nil #'=))
>       (cl--make-map-into-mapper sig))

I didn't now there was (setf if).  Good, I'll use it.  Only it would be
confusing to make cl-extra dependent on cl-generic.  with-memoization
better be in cl-lib proper which is also suggested in my cl-flet patch
(the big one).  I was unable to move it out of cl-generic into cl-macs
--- Emacs failed to build when I moved it and made an alias in
cl-generic.  Do you agree it should be moved, at least for the sake of
cl-map-into?  Actually, I think it could be “public” rather than --'ed.
Just make it with-memoization in subr-x or some other file that is
commonly required at build time, why not?

> - Since we're (weakly) promoting seq.el over cl-lib.el, I wonder if you
>   think it would be worthwhile to try and do something similar in seq.el?

None of seq- functions accepts arbitrary number of arguments so I don't
see how this particular dispatcher would be useful for seq.el.

However, this is an interesting topic.

seq.el was recently rewritten in terms of cl-generic which in my view
was wasteful and overall unfortunate.  I recently came to conclusion
that CLOS should only be used when method combination is used
significantly.  This conclusion is not shared by Common Lisp veterans in
#commonlisp at libera.chat which is the first time I disagree with
Common Lisp veterans on CL.  But still, it is not very surprising; looks
like method combination has been underappreciated since its inception.

seq- does not define a single class and I don't see how any of the
methods it defines could be conceivably combined with any other methods
imaginable.  That means, all the intricate dispatching powers of CLOS
are just wasted on seq.el.  Not only that; using CLOS introduces (for no
reason since inheritance ends up unused, with no prospective use cases
in sight) limitations on what seq's dispatchers could possibly do.
CLOS' dispatch is tailored for combining code by means of inheritance.
That means, types that can't be classes (i.e. types that are
incompatible with “most-specific” / “least-specific” ordering) are out
of service.  If one needs an interesting method for a type that can't be
a class (true for numeric ranges, for most of what modern compilers do,
you name it), one simply can't have it.

To conclude, I think seq would benefit from a different dispatch
mechanism that is not shoehorned into it.

signature.asc
Description: PGP signature