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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> is there some benchmark or test case that drives your desire to add
>> that bytecode?
> I don't have a specific benchmark in mind, but I did some tests with
> `benchmark-run` before I submitted the first patch to see how much
> faster it was.

I don't doubt it is faster in some tests, but that doesn't mean it will
make any difference to real world code.

> I didn't actually add a bytecode. Instead I re-purposed the = bytecode to
> handle both cases, since (= list1 list2) isn't acceptable anyway.

So you haven't really introduced a new `length=` but instead you've
changed the `=` function to (conceptually) coerce lists to their length.

> The only real downside to overloading this bytecode is a loss of
> type-checking to =.

You mean, the downside is that's an incompatible change.

> To compensate and aid in debugging any issues caused by
> this I made the compiler surround all the arguments to = with nonsense
> additions of 0 to regain the type-checking when `byte-compile-delete-errors`
> was nil. Consequently I changed that variables default value to t, otherwise
> you've lost more than you've gained by doing this.

These sound like ugly hacks.  I think it's better to take
your change upfront: make an incompatible change to `=` such that
`length` is automatically called on each argument if it's a list.

After all, we already coerce markers to ints, so it's not completely out
of place to coerce lists to ints (in the form of their length).

Furthermore, this could be seen as an improvement for package authors
(by making `=` more powerful), so it has merit regardless of whether or
not it makes a measurable difference to efficiency.

> So I suppose the first real issue is whether or not that change to
> `byte-compile-delete-errors` is acceptable,

It's not even the right question: your change modifies the behavior of
code compiled on earlier Emacsen as well and no amount of setting
byte-compile-delete-error will let the user recover the previous
behavior (at least until she recompiles the code).

If the backward-incompatible change of `=` is not considered acceptable,
then you'll either need a new bytecode, or live with a non-bytecode
C function.


        Stefan