From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lars Brinkhoff Newsgroups: gmane.emacs.devel Subject: Re: User-reserved element in byte code vectors Date: 05 May 2004 07:23:40 +0200 Organization: nocrew Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <85ekpz5twj.fsf@junk.nocrew.org> References: <85smepfzqo.fsf@junk.nocrew.org> <85ad0wfkms.fsf_-_@junk.nocrew.org> <85oepcdts4.fsf_-_@junk.nocrew.org> <85vfjf9s4j.fsf@junk.nocrew.org> <20040502094316.GB2836@fencepost> <85fzaiakb9.fsf@junk.nocrew.org> <20040503195701.GD21891@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083735535 27054 80.91.224.253 (5 May 2004 05:38:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 May 2004 05:38:55 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 05 07:38:46 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BLF7G-00058p-00 for ; Wed, 05 May 2004 07:38:46 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BLF7F-00027S-01 for ; Wed, 05 May 2004 07:38:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BLEx8-0000Gl-Qo for emacs-devel@quimby.gnus.org; Wed, 05 May 2004 01:28:18 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BLEx4-0000GN-G5 for emacs-devel@gnu.org; Wed, 05 May 2004 01:28:14 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BLEwa-00008c-NJ for emacs-devel@gnu.org; Wed, 05 May 2004 01:28:13 -0400 Original-Received: from [213.242.147.30] (helo=junk.nocrew.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BLEsf-0007Ym-CS; Wed, 05 May 2004 01:23:41 -0400 Original-Received: from lars by junk.nocrew.org with local (Exim 3.35 #1 (Debian)) id 1BLEse-0004Xi-00; Wed, 05 May 2004 07:23:40 +0200 Original-To: Miles Bader In-Reply-To: <20040503195701.GD21891@fencepost> Original-Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22786 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22786 Miles Bader writes: > On Mon, May 03, 2004 at 10:03:24AM -0400, Richard Stallman wrote: > > All else being equal, I would rather use bytecode objects than > > vectors for something funcallable. > If you just don't like vectors being funcallable, then of course > (e.g.) another special-purpose vector type could be used instead. > However it would be nice if it were printable, and if users could > set/access the elements easily; by using standard vectors, these > things come for free. It occurred to me that there already is funcallable vector-like type with all those nice properties: the bytecode type. If funcall was changed (and I don't know if this is acceptable) to "curry" in all bytecode elements after the 6th, that would work as well as Miles's funcallable vectors. E.g. Ffuncall could be changed to something like: if (COMPILEDP (fun)) { int size = XVECTOR (fun)->size & PSEUDOVECTOR_SIZE_MASK; if (size <= 6) /* The usual case, as before. */ val = funcall_lambda (fun, numargs, args + 1); else { /* This is adapted from Miles's funcallable vectors. */ int num_curried_args = size - 6; internal_args = (Lisp_Object *) alloca ((num_curried_args + numargs) * sizeof (Lisp_Object)); /* Curried args are first in the new arg vector. */ bcopy (XVECTOR (fun)->contents, internal_args, num_curried_args * sizeof (Lisp_Object)); /* User args are last. */ bcopy (args + 1, internal_args + num_curried_args, numargs * sizeof (Lisp_Object)); val = funcall_lambda (fun, num_curried_args + numargs, internal_args); } } This would be an incompatible change, but I don't think anyone relies on the old behaviour. -- Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/