From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: Consider adding hash-keys and hash-values Date: Sun, 3 Nov 2013 09:28:04 +0200 Message-ID: References: <1EA2626D6F9E40C799F18421D8FD41B5@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013d0dc07727e204ea40bdf8 X-Trace: ger.gmane.org 1383463688 16460 80.91.229.3 (3 Nov 2013 07:28:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Nov 2013 07:28:08 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Leo Liu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 03 08:28:13 2013 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 1Vcs6W-0000oQ-En for ged-emacs-devel@m.gmane.org; Sun, 03 Nov 2013 08:28:12 +0100 Original-Received: from localhost ([::1]:44313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vcs6V-0004ST-SG for ged-emacs-devel@m.gmane.org; Sun, 03 Nov 2013 02:28:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vcs6S-0004SN-5l for emacs-devel@gnu.org; Sun, 03 Nov 2013 02:28:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vcs6P-0007rm-RN for emacs-devel@gnu.org; Sun, 03 Nov 2013 02:28:08 -0500 Original-Received: from mail-oa0-x233.google.com ([2607:f8b0:4003:c02::233]:46766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vcs6P-0007rc-FK for emacs-devel@gnu.org; Sun, 03 Nov 2013 02:28:05 -0500 Original-Received: by mail-oa0-f51.google.com with SMTP id h2so413778oag.24 for ; Sun, 03 Nov 2013 00:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lK8+YSZgAb088Sm185PEoDlnYTqQDfcazRqtCZDrpic=; b=ciRX0UHbLjl7A6KC6Oq1NBss4VfsJSxWOywNggC+Uzv/EcFACaUa+c2kK4pbL912eo eUHeSBuPbWTIt3Yr291K0mEGl5uEU3PHyYCq5jSC2pVLjWW9YBDyut6A3Dg/MIcB+xWh Snxix4AktGMoCSTlvUuv+9HVd2FaoPDkzXdgh2Q/XqmzsIFva+YhGd8VbIONLLFg6eLi lCI/3j2fR06o1PwkThWCHNQnRL3gvwWt624pCrAOHOafORlpvhoozpTOWZ05BavC8hlE 537wj76v4Fhod1UeHbUBOKigX1OSWteTXuENkC9qEHzCZhDD9FOO3kjLBcLJUl11pHfT iUQg== X-Received: by 10.182.153.226 with SMTP id vj2mr9301771obb.26.1383463684350; Sun, 03 Nov 2013 00:28:04 -0700 (PDT) Original-Received: by 10.76.131.116 with HTTP; Sun, 3 Nov 2013 00:28:04 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: ZoN2zCnfCnA2Bd1eLuYzY3L9oag X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::233 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:164886 Archived-At: --089e013d0dc07727e204ea40bdf8 Content-Type: text/plain; charset=UTF-8 On 3 November 2013 04:38, Leo Liu wrote: > On 2013-11-02 23:27 +0800, Bozhidar Batsov wrote: > > I've attached a patch for your consideration. > > Personally I think such one-liners won't be of much use. The designer of > the hash table API would have considered such use cases and decided to > rule them out for good reasons. > I think this is the wrong kind of reasoning. The fact that something exists (or doesn't exist) doesn't mean necessary that it was carefully thought through. In the end of the day everyone makes design mistakes from time to time. I guess the original reasoning was to provide as minimalistic API as possible (or more likely - the API was modelled after Common Lisp, which doesn't feature those functions as well). APIs, however, should evolve and designers should always take account the way the API is actually used by its clients. Common Lisp doesn't have those functions, either, but they're included in the Alexandria library, that most Common Lisp projects use. The Common Lisp core is beyond extension for various unfortunate reasons, but Emacs is not... As I've originally said - I can't recall another programming language that doesn't have such methods in its standard library. > > Maybe start out as your personal project and see how people react to it > first? WDYT? > I've seen these functions inlined quite often into Emacs packages - obviously people use them. Don't think that a research paper is needed to warrant the demand for their inclusion. :-) Plus, as Stefan said - other non-essential utilities might be moved to the same library. > > Leo > --089e013d0dc07727e204ea40bdf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 3 November 2013 04:38, Leo Liu <sdl.web@gmail.com&= gt; wrote:
=
On 2013-11-02 23:27 +0800, Bozhidar Batsov wrote:
> I've attached a patch for your consideration.

Personally I think such one-liners won't be of much use. The desi= gner of
the hash table API would have considered such use cases and decided to
rule them out for good reasons.

I think= this is the wrong kind of reasoning. The fact that something exists (or do= esn't exist) doesn't mean necessary that it was carefully thought t= hrough. In the end of the day everyone makes design mistakes from time to t= ime. I guess the original reasoning was to provide as minimalistic API as p= ossible (or more likely - the API was modelled after Common Lisp, which doe= sn't feature those functions as well). APIs, however, should evolve and= designers should always take account the way the API is actually used by i= ts clients.

Common Lisp doesn't have those functions, either, b= ut they're included in the Alexandria library, that most Common Lisp pr= ojects use. The Common Lisp core is beyond extension for various unfortunat= e reasons, but Emacs is not...

As I've originally said - I can't recall anothe= r programming language that doesn't have such methods in its standard l= ibrary.
=C2=A0

Maybe start out as your personal project and see how people react to it
first? WDYT?

I've seen these functi= ons inlined quite often into Emacs packages - obviously people use them. Do= n't think that a research paper is needed to warrant the demand for the= ir inclusion. :-) Plus, as Stefan said - other non-essential utilities migh= t be moved to the same library.
=C2=A0

Leo

--089e013d0dc07727e204ea40bdf8--