From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: What's up with apply-partially? Date: Fri, 23 Jan 2015 23:14:06 +0100 Message-ID: <874mrh5emp.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422051271 15821 80.91.229.3 (23 Jan 2015 22:14:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 22:14:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 23 23:14:26 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YEmUk-00039J-AG for ged-emacs-devel@m.gmane.org; Fri, 23 Jan 2015 23:14:26 +0100 Original-Received: from localhost ([::1]:33326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEmUj-0001H2-Gq for ged-emacs-devel@m.gmane.org; Fri, 23 Jan 2015 17:14:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEmUg-0001Go-EB for emacs-devel@gnu.org; Fri, 23 Jan 2015 17:14:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEmUf-0002aw-HC for emacs-devel@gnu.org; Fri, 23 Jan 2015 17:14:22 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEmUf-0002as-DZ for emacs-devel@gnu.org; Fri, 23 Jan 2015 17:14:21 -0500 Original-Received: from localhost ([127.0.0.1]:55005 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEmUe-000060-VG for emacs-devel@gnu.org; Fri, 23 Jan 2015 17:14:21 -0500 Original-Received: by lola (Postfix, from userid 1000) id 48FB6E05F5; Fri, 23 Jan 2015 23:14:06 +0100 (CET) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181700 Archived-At: The original definition of apply-partially in subr.el by Eli in 2008 has been (defun apply-partially (fun &rest args) "Return a function that is a partial application of FUN to ARGS. ARGS is a list of the first N arguments to pass to FUN. The result is a new function which does the same as FUN, except that the first N arguments are fixed at the values with which this function was called." (lexical-let ((fun fun) (args1 args)) (lambda (&rest args2) (apply fun (append args1 args2))))) The current definition by Stefan, however, is (defun apply-partially (fun &rest args) "Return a function that is a partial application of FUN to ARGS. ARGS is a list of the first N arguments to pass to FUN. The result is a new function which does the same as FUN, except that the first N arguments are fixed at the values with which this function was called." `(closure (t) (&rest args) (apply ',fun ,@(mapcar (lambda (arg) `',arg) args) args))) Now subr.el has lexical-bind set. It seems quite pointless to return some unevaluated quoted list here (apply-partially is not a macro but a function!). So why not just (defun apply-partially (fun &rest args) (lambda (&rest args2) (apply fun (append args args2)))) Where is the point in the complicated redefinition that returns a basically uncompiled function? Why not just take Eli's definition and simplify it in line with lexical-binding now being set? I don't understand the point of the change. Lexical bindings should have made this function more straightforward. Instead it has become more complex and unevaluated. And it's not like describe-function even knows `closure', as opposed to `lambda'. So it's become inscrutable as well. -- David Kastrup