From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Make register easier to hook Date: Mon, 28 Mar 2011 19:14:55 -0700 Message-ID: <4D91409F.6030702@gmail.com> References: <4D90C741.2090808@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1301364910 2940 80.91.229.12 (29 Mar 2011 02:15:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 Mar 2011 02:15:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Leo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 29 04:15:06 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4OSW-0008Dt-Db for ged-emacs-devel@m.gmane.org; Tue, 29 Mar 2011 04:15:04 +0200 Original-Received: from localhost ([127.0.0.1]:37623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4OSV-0000tz-TY for ged-emacs-devel@m.gmane.org; Mon, 28 Mar 2011 22:15:03 -0400 Original-Received: from [140.186.70.92] (port=35468 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4OSS-0000tl-3E for emacs-devel@gnu.org; Mon, 28 Mar 2011 22:15:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4OSQ-0001yJ-Tf for emacs-devel@gnu.org; Mon, 28 Mar 2011 22:14:59 -0400 Original-Received: from mail-pz0-f41.google.com ([209.85.210.41]:38049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4OSQ-0001yF-Nb for emacs-devel@gnu.org; Mon, 28 Mar 2011 22:14:58 -0400 Original-Received: by pzk32 with SMTP id 32so894714pzk.0 for ; Mon, 28 Mar 2011 19:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VnHz2Ra1/pP+JTqhxK5hZe2Zzevr9lCfdOI39A/H3Ds=; b=CLvxVsiyCRWemdNdbnwmTQSnMU7fYjhE8MObhrG6xa2IKUfw1SaCyAx4RbH07QRsyk HDiIiUh8qS9pdZR2So6qo/DPNKOPvXJvFSXGTJX+MAkbQkwc4Iwa11mpf3oWL7uH75Bh vS9JrYYxzUPW558p2vBXFEZKcPtXQ+fRP1WSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=i5NTnHIuj6woJ5U3VZ8jcaHVVd3IcabiMInZtQdN9JKgjKx3Bd67mPxzpPYvzeyG0m TYqfqaSeezBfyuUcHYMzF4+G95DMIRUURxLBEiupTP5EI7Mh0arSxjtTn75e00LFw/Sa vvGxQEITy6LMKJ1wec5UwmdrCbqnkTC6o83ZA= Original-Received: by 10.142.218.15 with SMTP id q15mr4383519wfg.311.1301364897323; Mon, 28 Mar 2011 19:14:57 -0700 (PDT) Original-Received: from [0.0.0.0] (c-67-183-23-114.hsd1.wa.comcast.net [67.183.23.114]) by mx.google.com with ESMTPS id o11sm6609969wfa.12.2011.03.28.19.14.55 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 19:14:56 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137829 On 3/28/2011 5:52 PM, Leo wrote: > On 2011-03-29 01:37 +0800, Daniel Colascione wrote: >> Thanks for doing this work. An extensible register system is also on my >> wishlist. Why did you decide to use the list for the register structure >> instead of the default vector representation? > > Probably because it looks nicer inside register-alist and there is > little performance to lose. > >> Also, have you considered eliminating the `info' slot? Users can >> construct closures over any necessary variables and assign these >> closures to the register structure's remaining function slots. After >> all, we're getting lexbind, and this feature will make constructing >> closures both easy and safe. > > Now I do. But I fail to see how that makes things more convenient. The > closures must be created inside the command/function that creates the > register, right? So one won't be able to define functions with defun for > the slots. Did I miss something? Well, when we get lexbind, we'll be able to write something like this safely, cleanly, and efficiency: (defun foo-register-jump (some-datum) "Implement the jump operation for registers with foo values." ... ) (defun foo-register-assign (register some-datum) "Assign a foo register value to some register" (register-set register (register-make :jump-func (lambda () (foo-register-jump some-datum)))) Today, we'd have to write this instead for the same effect: (defun foo-register-assign (register some-datum) "Assign a foo register value to some register" (lexical-let ((some-datum some-datum)) ; <----- HACK -------< (register-set register (register-make :jump-func (lambda () (foo-register-jump some-datum))))) I still think the version with lexical-let is cleaner than using a separate data value, especially because you can easily close over multiple variables without having to build some aggregate data structure to hold them. By the way: I'd also suggest calling the structure register-value or somesuch. It's confusing to have the same word refer to the *identifier* for the register (a, b, c, ...) and for the thing *inside* a register (a window configuration, a marker, a string, etc.)