From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Sat, 11 Nov 2023 21:57:02 -0500 Message-ID: References: <46ab3c7d-d820-4bb4-8ec4-97c614d7c8a0@alphapapa.net> <871qd8sfdx.fsf@posteo.net> <838r7g8pys.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38695"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 12 03:58:01 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r20ff-0009jv-F6 for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Nov 2023 03:57:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r20en-0000W9-7I; Sat, 11 Nov 2023 21:57:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r20el-0000Vi-IO for emacs-devel@gnu.org; Sat, 11 Nov 2023 21:57:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r20el-0006M1-Ai for emacs-devel@gnu.org; Sat, 11 Nov 2023 21:57:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=eTlEihU6oEcg1pNVd6e3trE67udQHFVWmb6fk6KRueE=; b=h9TqgcLNKZfN 8ozSbr/SrtDeGF7ScIqV0HiR3l9tKU2YCsJv1U40lamopo6g6wT9Qme9MDDQOOkdEvUBCNjRtlVnx etygtZN7XcU2cl9kybeV/bowqp2URp+ocrHyCeVNNctVOowRsHHWT4LH0y4kcy47FJTSeCNP3V5wW OKaQJT9YedYKJS5eAuCevUTCWhs3DbYT0YGsni96Pkq25cXPLdYRTQOYLEqo6gBURUNYHfgLwTHTH qYEzQJYlkouDTrmQbXdPxmiKBFB3m6B3p0Cez9l3wfgHWtFaaPju7qxNykYyIIITFsVf6mBGS5eoU oSev53vfMyU6mJ5Iwq4O4A==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1r20ek-0005Pf-Je; Sat, 11 Nov 2023 21:57:02 -0500 In-Reply-To: <838r7g8pys.fsf@gnu.org> (message from Eli Zaretskii on Thu, 02 Nov 2023 11:27:39 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312628 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > what constitutes "Emacs Lisp"? It would > > seem peculiar if it were to be defined by the arbitrary decisions of the > > past, constrained by the contingent circumstances of the time. > Those "arbitrary decisions" are what got us to where we are now, 40 > years later. So some respect for those "arbitrary decisions" is due, > I think. Not only that, but -- these decusions were not arbitrary in the first place. They were based on thought and embodied an idea of design. That's why they add up to a coherent whole. And yes, they add up to Emacs Lisp as it is -- "where we are now" is the sum of them. > > 1. Not standardised; it is possible to extend the language without > > having to worry about how many implementations will follow along > IMNSHO, extending Emacs Lisp as the language is not the main goal of > Emacs development. Emacs Lisp is not a programming language on its > own, it is a language for implementing and extending features and > extensions in Emacs. That is absolutely right! But there is a second error in the point (1) that you are responding to: the idea that extending a license is good, that more complexity in the form of language constructs Complexity of a language imposes a cost on all users of that language. Sometimes the right choice is to refuse ti extend the language. > > Emacs Lisp can learn from interesting ideas that other > > languages provide, adapt and add them, making them available to > > everyone. > It certainly can. The question is: should it? Since we are not > driven by any standard, it is completely up to us to make those > decisions, and we should IMO make them judiciously and carefully, > taking the downsides into consideration. In particular, I hope people > agree that making a language too large and complex is not a good > thing in the long run. I think the same. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)