lengths and stuff

[Daniel Brooks]

Drew Adams <drew.adams@oracle.com> writes:

> With that "solution" you've only added a new problem: you
> now need to advertise the new functions and advise users
> to use them, not `length', in such a use case.  Which
> means you still have the need to identify the relevant use
> cases, which means teach them about the `length' gotcha
> (or hope they follow advice without understanding).  IOW,
> now you have 2 problems...

Users certainly do need to know the performance cost of the functions
that they use. But they also need alternatives. If (> (length list) n)
is a trap for new players, then document it as so _and_ mention that
there is a specific function that can be used to avoid the trap. But
it's also worth mentioning that maybe the code should use a vector
instead of a list, if the length is so important.

Also, as was pointed out, this very thing happens 735 times in the Emacs
lisp codebase. Probably most of those have no great performance impact,
but it's a good observation.

> [Personally, in the case considered, I'd use (cdr x).
> I wouldn't use (not (null (cdr x))).  And it doesn't
> get simpler _or clearer_ than that, IMO.]

True. It's not the first time I've noticed myself making something more
complicated by eagerly converting to a boolean. But I still don't think
that it's readable code.

db48x