From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: map.el and naming Date: Mon, 2 Mar 2015 14:33:14 +0000 Message-ID: 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: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1425306842 26585 80.91.229.3 (2 Mar 2015 14:34:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Mar 2015 14:34:02 +0000 (UTC) Cc: Nicolas Petton , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 02 15:34:00 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 1YSRPz-0004jt-HZ for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 15:33:59 +0100 Original-Received: from localhost ([::1]:57447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSRPy-0004uL-Sl for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 09:33:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSRPJ-0004MO-W1 for emacs-devel@gnu.org; Mon, 02 Mar 2015 09:33:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSRPI-000589-V4 for emacs-devel@gnu.org; Mon, 02 Mar 2015 09:33:17 -0500 Original-Received: from mail-oi0-x229.google.com ([2607:f8b0:4003:c06::229]:62629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSRPH-00057l-Mi; Mon, 02 Mar 2015 09:33:15 -0500 Original-Received: by mail-oi0-f41.google.com with SMTP id z81so27210378oif.0; Mon, 02 Mar 2015 06:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=X5jj0QNWFCx6JH3i99mRJosM1ANibuf9w/Y82ZBa1C4=; b=TouEbYuSdhH57NRqw1hZIOjx1KmxlJ2jODXXK6pXY7NiiUwmvxYc1QlIPWrA6XLQzg WOml3xYYGE4ybw+mg+PmqUo5tqivJGmb1y11f+jeC2+VaOJixjDE2r16P0ocG8q/S4Os KbB7wIWhv5EaP+RFSoFQq4T34iF07n27aRfwnJTtdWqH42tk8DwnTtu+70ztfo3N8brc roZf3xKiDDxNf8ET0lKe5wLFEwufkE7loZVd54gg7/cD4/zSs8G6ZCakvmTpeTt42erK zsivDGVw+oj7U8snKw+qQQWBGG2k2emyY0bVSp/x//v5rMjHq7z/OLegaHfhHlgxi3X3 h4jQ== X-Received: by 10.202.218.135 with SMTP id r129mr18375086oig.26.1425306795066; Mon, 02 Mar 2015 06:33:15 -0800 (PST) Original-Received: by 10.76.130.17 with HTTP; Mon, 2 Mar 2015 06:33:14 -0800 (PST) In-Reply-To: <8361ajsduy.fsf@gnu.org> X-Google-Sender-Auth: X08bRtNCYEOzC3c8XL4Pnq8QMWA X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c06::229 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:183569 Archived-At: > 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). > Do any of the operations in seq.el make sense with the > objects you meant to handle in map.el? If so, it could make sense to > have them treated by the same API. Many certainly do, but the way they must be handled is different for sequences and associations. For instance, if you map over a list, you want the function will be called on each element, but if you map over an association, you want the function to be called on each key-value pair. 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). 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').