[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: [PATCH] Add new lisp function length= with bytecode support
Date: Wed, 08 Mar 2017 11:47:51 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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

Indeed, it's a bit more incompatible.  But it's easier to describe the
incompatibility: in your case it occurs in some cases and not in others,
depending a whether something is byte-compiled or not and with which
Emacs and which value of some fairly obscure compilation flag.

> Personally I would think coercing sequences to their lengths in =
> would be even more confusing.

Could be, indeed.  But in any case, that's what your code does, so
better be prepared to defend this choice ;-)

>> 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=?

I don't know.  I didn't mean to promote this change.  I was just
pointing out that (as maintainer) I'd be more willing to accept such an
upfront change, than one that introduces an incompatibility in more
sneaky ways.  I'm not sure I'd accept either of them.

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

That might be a better option, with more visible effects.  The issue is
that bytecode space is limited (and very difficult to recover later on),
so I'd be reluctant to add new bytecodes without some clear benefit.
So some real-life measurements of speed up would go a long way.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]