all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: [PATCH] Add new lisp function length= with bytecode support
Date: Wed, 08 Mar 2017 11:47:51 -0500	[thread overview]
Message-ID: <jwvzigv204u.fsf-monnier+gmane.emacs.devel@gnu.org> (raw)
In-Reply-To: ps1nEeFoHoQW6LaWqB7lNoqEROPaAP_VLKKjYQMqDGhSHBc-XDdUSBp-BzY0QFCNgDmDh3kfULoqGy9tT1ks2TB7iVCRYZ-ikSnyC6dmuVQ=@protonmail.com

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


        Stefan




  reply	other threads:[~2017-03-08 16:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-07 13:52 [PATCH] Add new lisp function length= with bytecode support Constantin Kulikov
2017-03-08  2:00 ` Gdobbins
2017-03-08  2:46   ` Stefan Monnier
2017-03-08  3:31     ` Gdobbins
2017-03-08  4:13       ` Stefan Monnier
2017-03-08  7:01         ` Gdobbins
2017-03-08 16:47           ` Stefan Monnier [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-02-26 22:04 Gdobbins
2017-02-27 16:14 ` Eli Zaretskii
2017-02-27 18:43   ` Gdobbins
2017-02-27 23:06     ` Paul Eggert
2017-02-28  0:35       ` Gdobbins
2017-02-28  9:24 ` Andreas Schwab
2017-03-06  1:59   ` Gdobbins
2017-03-06  6:13     ` Elias Mårtenson
2017-03-06  7:43       ` John Wiegley
2017-03-06 18:00         ` Richard Stallman
2017-03-06 20:36           ` Gdobbins
2017-03-06 20:45             ` Clément Pit-Claudel
2017-03-06 21:03               ` Gdobbins
2017-03-07  0:29                 ` Gdobbins
2017-03-10 10:20                   ` Ken Raeburn
2017-03-10 22:25                     ` Gdobbins
2017-03-13  2:51                       ` Gdobbins
2017-03-13  3:20                         ` Stefan Monnier
2017-03-14  6:06                           ` Gdobbins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvzigv204u.fsf-monnier+gmane.emacs.devel@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.