Re: [PATCH] Add new lisp function length= with bytecode support

[Gdobbins]

> It should be documented in doc/lispref/sequences.texi, no?

Yes, of course. Sorry about that.

> As the intended use of length= is to compare lengths, it's confusing

> that it also accepts markers and floats, plus that makes the

> implementation a bit slower as it can't use EQ to compare lengths. It

> would be cleaner and simpler for length= to accept only sequences and

> integers, as Alexandria does.

I'm not sure I understand how EQ can be used to compare lengths. Do you mean using EQ to compare the numbers in the way I was using Feqlsign?

> I assume that markers and floats were put in only so that the

> byte-compiler could optimize expressions like (= (length FOO) BAR)

> without worrying about incompatibilities in the very-unlikely case where

> BAR is a float or a marker. In that case, perhaps the the byte-compiler

> should use a specialized length= function that is not visible to the

> user, so that the user-visible function (if any) can be kept cleaner.

length= accepts floats and markers so that the byte-code for = "" be changed to actually call length=, since as it is currently defined length= returns the same result as = when given arguments appropriate for =. In this way both = and length= can be byte-compiled without the need for a new byte-code. The function length_eqlsign2 could be left this way and the full Flength_eqlsign could be changed to accept only integers. This should accommodate also the case you mention of BAR being a float or marker, provided the compiler macro be changed as necessary. I found less than ten cases where = was used to compare more than two sequences/numbers anyway.

I'm happy to make these changes and submit a new squashed patch, but first I'd like to know the consensus on whether or not my changes to the byte-compiler are acceptable. Otherwise these patches of patches are likely to become unwieldy.

-- Graham Dobbins