From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: `thunk-let'? Date: Thu, 9 Nov 2017 13:05:42 -0800 (PST) Message-ID: <8ae533ea-f8fe-4b65-a6cc-8ce332d94d22@default> References: <87infp9z6j.fsf@web.de> <87zi90eehg.fsf@web.de> <87o9ocd6s4.fsf@web.de> <83zi7wr6jc.fsf@gnu.org> <87k1z0csxa.fsf_-_@web.de> <83k1yzqshk.fsf@gnu.org> <87vaijwclj.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1510261562 5986 195.159.176.226 (9 Nov 2017 21:06:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Nov 2017 21:06:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Heerdegen , =?utf-8?B?Q2zDqW1lbnQgUGl0LUNsYXVkZWw=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 09 22:05:58 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCu1L-0001Ff-4t for ged-emacs-devel@m.gmane.org; Thu, 09 Nov 2017 22:05:55 +0100 Original-Received: from localhost ([::1]:38796 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCu1S-0005Tl-FP for ged-emacs-devel@m.gmane.org; Thu, 09 Nov 2017 16:06:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCu1M-0005Tf-2t for emacs-devel@gnu.org; Thu, 09 Nov 2017 16:05:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCu1H-0004Mc-4f for emacs-devel@gnu.org; Thu, 09 Nov 2017 16:05:56 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:26319) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eCu1G-0004Kr-RS for emacs-devel@gnu.org; Thu, 09 Nov 2017 16:05:51 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA9L5kk1002174 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Nov 2017 21:05:46 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA9L5jJe022943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Nov 2017 21:05:45 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA9L5hDY000645; Thu, 9 Nov 2017 21:05:45 GMT In-Reply-To: <87vaijwclj.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:220008 Archived-At: > I think it certainly is useful. And it allows you to write nicer code > because you don't have to use (low-level) thunk objects explicitly > (thus, it's a reasonable abstraction). I'm just only 97%, and not 100%, > sure that it is the optimal solution for the problem it solves. > > So, "half baked" is an exaggeration. Anyway, the macro makes it much > easier to write more efficient code in an easy way and clean style, so I > don't doubt it is useful now, in Emacs. FWIW: I'm the one who used the term "half-baked". But I did not mean to suggest that this contribution is in any way half-baked. Knowing your work a bit, Michael, I'd assume that this is not at all half-baked. (Not that there is anything wrong with stuff that is half-baked - it too can be useful.) I questioned only the purpose of having a library, apparently `subr.el', whose _purpose_ is to act as a sort of sandbox of stuff that, for whatever reason, someone doesn't consider quite ready for primetime. To me, whatever we deliver as part of Emacs should be considered supported (until it's not). If we're really worried about the quality of something then the choice is not to deliver it. If we deliver something to users we should put it in an appropriate file to begin with, not in a special "sandbox" file. And whether to document something in the manuals should not depend on how polished we think it might be. Other criteria (the usual ones) should decide inclusion in a manual. Those are the only points I meant to make, when I said: "Whether we should have a library that is for "half-baked" stuff is debatable." "I don't think it makes sense to decide whether something gets documented in the manuals based on how well baked we think it is." "We should WANT users to try half-baked stuff that we deliver. That's how it gets improved."