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

[Gdobbins <gdobbins@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

> 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.

That's a judgement call I can't make. I will point out though that it is more incompatible than the change I've proposed, since there wouldn't be any way to get the old behavior back (even if it took recompiling). There was also contention with my original length= for accepting markers and floats, citing confusion. Personally I would think coercing sequences to their lengths in = would be even more confusing.

> 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.

I guess, but is it really any more powerful than a separate length=? If length= were to go back to accepting floats and markers it would then be an = which coerces lengths to ints. What about the other comparison operators <,> etc. that were previously asked for, should they be changed as well? My original intention with this patch was just to port length= from CL which I already do find useful.

> 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.

It really doesn't matter to me. I expected there to be objections to that change, which is why I put them in a separate commit from defining length= in the original patch I submitted. Since most of my first message was about the changes to the bytecode and no-one mentioned anything about it I assumed it was acceptable.

Since it's being discussed, a single new bytecode should be able to encompass all of the length=, length<, etc. functions if it's decided to go that route. As I've stated previously around 50% of all calls to length are then fed straight into =, <.>, etc., so it may be worth it.


-- Graham Dobbins

[-- Attachment #2: Type: text/html, Size: 2544 bytes --]