Re: can `shuffle-vector' be moved?

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 13 May 2011 12:26:34 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>> OK.  Can there be a cl-macs-extras.el for "general cl-macs based code
>> that is safe to include in ELisp code"?

SM> I really have no idea why you want it in cl-macs:
SM> 1- the "macs" part refers to "macros", your function isn't one.
SM> 2- it does not provide a CL-style function.
SM> 3- using a CL macro in its definition is a property share by a lot more
SM>    code than just the CL code.  And actually, the cl*.el files tend not
SM>    to use CL features, to avoid circular dependencies.

I was trying to say "miscellaneous functions that require cl-macs.el."
I think the value of the loop-based `shuffle' is code brevity and
clarity; otherwise it's no better than `shuffle-vector' and has a
startup penalty if you don't have cl-macs.el loaded.  So if you don't
think it's worth keeping it around for those qualities, I have no
problem with dropping it.

>> but that's an inconsistency all the cookie1.el functions have.

SM> The only other function I see in cookie1.el that does not use the
SM> "cookie-" prefix is "read-cookie", which is borderline acceptable (we
SM> have a few such "shared prefixes" like "turn-on-").

I mean that they all have the "cookie-" prefix while the package is
called cookie1.el.

SM> So, `shuffle-vector' does indeed stand out.  And the fact that it's
SM> autoloaded is a clear sign it is intended to be used by other
SM> packages.  But I see no good place to put it right now, and I don't
SM> think it deserves creating a "misc-lib.el" for itself (although some
SM> of the functions in subr.el might be good candidates for such a new
SM> package).

Yes, maybe we're at the tipping point where it's worth breaking up
subr.el into subr-vec.el, subr-list.el, subr-alist.el, etc.  OTOH it's
nice to have them in one place.

Ted