From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: map.el and naming Date: Tue, 03 Mar 2015 12:14:12 +0900 Message-ID: <87egp6bwmz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87lhji1aw8.fsf@petton.fr> <8361amtabg.fsf@gnu.org> <87ioej26ij.fsf@petton.fr> <83fv9nsfht.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1425352497 10607 80.91.229.3 (3 Mar 2015 03:14:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Mar 2015 03:14:57 +0000 (UTC) Cc: Eli Zaretskii , Nicolas Petton , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 03 04:14:41 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 1YSdI8-00067e-Tk for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 04:14:41 +0100 Original-Received: from localhost ([::1]:33113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSdI7-0003kG-Tm for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 22:14:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSdHu-0003k7-6a for emacs-devel@gnu.org; Mon, 02 Mar 2015 22:14:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSdHt-0004Wd-2T for emacs-devel@gnu.org; Mon, 02 Mar 2015 22:14:26 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:47873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSdHp-0004UV-7G; Mon, 02 Mar 2015 22:14:21 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 9DB731C3867; Tue, 3 Mar 2015 12:14:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 771E11A26E3; Tue, 3 Mar 2015 12:14:12 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:183589 Archived-At: Stefan Monnier writes: > > of these objects: lists, strings, vectors, alists, and hash-tables? > > Think of `seq' and `map' as (Java) interfaces, which can be implemented > by various low-level representations. > > Some representations (e.g. lists or vectors) can implement both interfaces. Please, let's not go there. Emacs Lisp is by design, history, and current practice in Emacs primarily a non-object-oriented language. It's not object-oriented at the level of Java or Haskell, and certainly not Smalltalk. Granted, it is certainly possible to implement true[1] objects in Lisp, and it's a very valuable technique in Emacs too (eg, the various components of CEDET). But the "objects" listed in the quote above are not objects in this sense. They don't know their own subclass, and so cannot tell a function operating on them that "I'm a cons" (Lisp knows that) "which is the head of a list representing a map using the 'property list' API" (Lisp can't know that for those objects). This is a deliberate design principle; RMS wanted Emacs data structures to be introspectable, and he chose to do that by avoiding ADTs except where absolutely necessary for efficiency (buffers, strings, vectors, hash-tables), and instead building everything out of a few primitive data types and embedding knowledge of data structures in functions. This allows a person with access to the source of those functions to introspect the corresponding data structures. (How 1970s! Sure, but that's when Emacs was designed....) Certainly it's possible to implement polymorphic functions, too. But here, AFAICS we already have the useful ones for sequences (nth, for one). I agree that "cons", "car", and "cdr" are not very discoverable for new learners, but then the ambiguous use of "map" (as a verb, it either means "iterate over a sequence" or "describe a functional relationship") is hardly helpful to them. I really don't see what benefit these new faux-namespaces (seq.el, map.el) provide, except to worshippers of consistency. This is quite different from the situation with cl-lib, where Common Lisp often uses the same identifiers as Emacs Lisp with different semantics, and also often provides rather sophisticated functionality that is not necessary in "base Emacs" (though extremely expressive and useful in the advanced applications which make Emacs so powerful). If you want to build an object-oriented language into Lisp, great. But first you need objects. (XEmacs already uses OO implementation techniques at the C level, but I gather from other threads that in Emacs such usage is spotty at best.) We already have EIEIO. That may not be appropriate for "promotion" into the core language, or perhaps people would prefer CLOS or maybe something more appropriate for an eventual Guile-based Emacs "Lisp". Footnotes: [1] By which I mean in the conventional sense of "object orientation".