Would (cycle-list <ls>) be a bad idea?

Question

Would you consider something like this a bad practice?

(defun cycle-list (ls &optional backward?)
  "Given any list, returns the next element each time it is called."
  (let* ((last-pos (- (length ls) 1))
         (maybe-counter (gethash ls cycle-list-counter))
         (cal-counter (if maybe-counter
                          (if backward?
                              (- maybe-counter 1)
                            (+ maybe-counter 1))
                        0))
         (counter (cond ((> cal-counter last-pos) 0)
                        ((< cal-counter 0) last-pos)
                        (t cal-counter))))
    (puthash ls counter cycle-list-counter)
    (nth counter ls)))

I wrote it because it is pretty handy, e.g. I used it to write another function which cycle between themes.

Surely, it shouldn't be used with simple lists, such as '(1 2 3), or in place of (do-list ...). But also, say we add one more theme to (custom-available-themes), now the previous hash-key is left unused.

I suppose in this particular case of theme cycling, there is probably a way to deal with this but: I want to know if the function (cycle-list ...) itself to you seems bizarre.

Answer 1

There are problems with cycle-list as you have defined it.

• It seams that you want to apply cycle-list on list variables that you actually do not have control of. What happens if someone uses push, delq, nconc, cl-nset-difference, or similar functions on such a list? Your counter would be invalidated by that.
• If, because of the previous item, you define your own list, you can choose the type of the list yourself. You actually have a ring-type of list. Depending on the use-case there are built-in types for that. See. e.g., M-: (info "(elisp)Rings") or see how the kill-ring is implemented (M-: (info "(elisp)The Kill Ring") ).
• The byte-compiler would moan about your code because you use a variable cycle-list-counter that is not declared as special with defvar or defvar-local. (defvar declares the lookup for the symbol-value as always dynamically scoped.)
• Currently you do not differentiate between global list variables, buffer-local list variables, and list variables that just have buffer-local values in some buffers. Maybe, that aspect could be fixed by declaring cycle-list-counter buffer locally and using either its value or its default-value.