From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Goel Newsgroups: gmane.emacs.devel Subject: changing multiple-value calls in emacs code. Date: Fri, 13 Mar 2009 15:42:02 -0400 Message-ID: <87fxhh5hx1.fsf@marie.gnufans.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1236973363 30899 80.91.229.12 (13 Mar 2009 19:42:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Mar 2009 19:42:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 13 20:44:00 2009 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.50) id 1LiDIR-00026I-3o for ged-emacs-devel@m.gmane.org; Fri, 13 Mar 2009 20:43:55 +0100 Original-Received: from localhost ([127.0.0.1]:36530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LiDH5-0006t6-3A for ged-emacs-devel@m.gmane.org; Fri, 13 Mar 2009 15:42:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LiDGp-0006on-Jy for emacs-devel@gnu.org; Fri, 13 Mar 2009 15:42:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LiDGk-0006ml-Tp for emacs-devel@gnu.org; Fri, 13 Mar 2009 15:42:14 -0400 Original-Received: from [199.232.76.173] (port=36037 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LiDGk-0006mg-Jk for emacs-devel@gnu.org; Fri, 13 Mar 2009 15:42:10 -0400 Original-Received: from mta11.charter.net ([216.33.127.80]:49917) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LiDGk-0002VG-8h for emacs-devel@gnu.org; Fri, 13 Mar 2009 15:42:10 -0400 Original-Received: from imp11 ([10.20.200.11]) by mta11.charter.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090313194202.KTEC21265.mta11.charter.net@imp11> for ; Fri, 13 Mar 2009 15:42:02 -0400 Original-Received: from marie.gnufans.net ([24.197.155.76]) by imp11 with charter.net id Sji21b00Q1fAMNY05ji2ca; Fri, 13 Mar 2009 15:42:02 -0400 Original-Received: from deego by marie.gnufans.net with local (Exim 3.36 #1 (Debian)) id 1LiDGc-00050g-00 for ; Fri, 13 Mar 2009 15:42:02 -0400 X-Face: #5@=vrmx5t3mZaPY8(mR.n+V#:%4NW7j5A&^}@lGp2rK; CQ4%iH1v'gh/^A)w5*6c&R2(P' 4+seYDq8OK'LPI/C(C^A*w|f*t+8, 'T8b#_0~h3!A7GoVroE[cr0Fb'A0%SdU|Lk@gBV&1vA User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) 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:109607 Archived-At: There are a very few places in emacs that do things like (multiple-value-bind). As we know, this does not in reality use any m-v facility, mostly it is meant to bind vars to a list, rather than to a host of values. Indeed, (values-list) is an identity. In such cases, the right thing to do would be to change such calls: (multiple-value-setq (a b) (foo)) to (multiple-value-setq (a b) (values-list (foo))). While the former is == the latter, the latter is the proper "RIGHT" way of setq-ing a and b to members of a list. I have committed some such changes. Please let me know if you think I did anything wrong. It is just a cosmetic change, since values-list just returns its argument unchanged. ---- It is much rarer still that a function actually invokes any m-v facility and returns (values ..) in its output. This happens only in mh.el .. In emacs, we want to stay away using m-v, and such (values) should be changed to (list.. ). Of course, this is again a cosmetic change. The uses of these values should again be used by (multiple-value-bind ... (values-list ... )) ---- I restress that any changes I made above are merely cosmetic changes. (But, with a proper m-v facility, like the one I am proposing, these changes will matter. Furthermore, these changes ensure that we never use m-v facitily by default any way.)