From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: map.el and naming Date: Mon, 02 Mar 2015 16:49:37 +0200 Message-ID: <83y4nfqwse.fsf@gnu.org> References: <87lhji1aw8.fsf@petton.fr> <8361amtabg.fsf@gnu.org> <87ioej26ij.fsf@petton.fr> <83fv9nsfht.fsf@gnu.org> <87h9u31qek.fsf@petton.fr> <8361ajsduy.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1425307807 11310 80.91.229.3 (2 Mar 2015 14:50:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Mar 2015 14:50:07 +0000 (UTC) Cc: nicolas@petton.fr, emacs-devel@gnu.org To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 02 15:49:59 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 1YSRfT-00037y-5w for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 15:49:59 +0100 Original-Received: from localhost ([::1]:57491 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSRfS-000788-Nj for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 09:49:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42758) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSRfO-000781-7h for emacs-devel@gnu.org; Mon, 02 Mar 2015 09:49:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSRfK-0001dv-Qo for emacs-devel@gnu.org; Mon, 02 Mar 2015 09:49:54 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:61601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSRfK-0001dl-IL for emacs-devel@gnu.org; Mon, 02 Mar 2015 09:49:50 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NKL00400A7BLM00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Mon, 02 Mar 2015 16:49:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NKL004RCAIYJ060@a-mtaout23.012.net.il>; Mon, 02 Mar 2015 16:49:47 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:183570 Archived-At: > Date: Mon, 2 Mar 2015 14:33:14 +0000 > From: Artur Malabarba > Cc: Nicolas Petton , emacs-devel > > > But polymorphism _is_ about using the same APIs for treating different > > objects. > > Yes, but associations (or maps) and sequences are not just different > objects, they're different abstractions too. There are many operations > which make sense on both, but even then Emacs has no automatic way of > deciding which version to employ (see below). I thought the object type should give enough information about that. > Now, take a plist as an example. If you call `seq-map' on a 2-element > list where the first element happens to be a keyword, `seq.el' has no > way of knowing if you intended to use that as a sequence or as an > association, therefore it just can't handle both cases. > That's why you need two libraries. If you want to map over sequences, > you call seq-map, if you want to map over an association, you call > `map-map' (or whatever it ends up being called). I asked whether it would make sense to have the same APIs for both groups, and where just the type of the object provides enough information for choosing how to process it. If you are saying that doesn't make a lot of sense, then I guess polymorphism doesn't make much sense in this case. > This won't only happen with mapping, I think it will happen with > enough other functions to warrant a different library. Of course this > library doesn't have to reimplement everything from scratch, it can > and should fallback on seq.el whenever possible (just like seq.el > sometimes falls back on built-ins like `mapcar'). If there are APIs that make sense for maps, IMO they should be generic APIs that can handle both objects now handled by seq.el and those in map.el. IOW, if only some of the APIs must be map-specific, that doesn't mean we need to make them all map-specific, IMO.