From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Wed, 6 Sep 2023 11:29:11 +0000 Message-ID: References: <87ledwx7sh.fsf@yahoo.com> <877cpfybhf.fsf@yahoo.com> <873503y66i.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36252"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , luangruo@yahoo.com, emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 06 13:29:36 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 1qdqj2-0009Ed-32 for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Sep 2023 13:29:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdqin-0007QT-9A; Wed, 06 Sep 2023 07:29:21 -0400 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 1qdqik-0007Q4-Kf for emacs-devel@gnu.org; Wed, 06 Sep 2023 07:29:18 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdqih-0008AB-Qv for emacs-devel@gnu.org; Wed, 06 Sep 2023 07:29:18 -0400 Original-Received: (qmail 67043 invoked by uid 3782); 6 Sep 2023 13:29:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693999753; h=date : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from : from; bh=+VpVtudsiGiyHZnd5apfpsCaVEotfN5WNf6k0TVLcK4=; b=oB4ofDt/24op+RhkheHxZKgkH362jHCNT8mh24pz/LpqtaFgs4XoPcCLrYaBAeaChyr5H 7GpK1vAJXarNzCbkksN21ejkbt57q7yyZZ3x6W7iSsnFLfprHop0VXa0+5Km4fp9SgCNPBm SpOwKOIl9nInKTIrws/aAudLnHN0CFct8GqWhhQzjFEoG9aKrmglZdKGvKlxE6UT6Azd7f0 R07FBtLwgR6nI7My79iARpF/sRO4UCnKXpbhwBHvulPGpW5N5VpOfEedN85AyVL6TkFHeD8 +AEMgss/hZCtx9BsVcJmzbGOE8cd56lybpBJqq/HLUSATa++Y2pReHqNofpg== Original-Received: from acm.muc.de (p4fe1538c.dip0.t-ipconnect.de [79.225.83.140]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 06 Sep 2023 13:29:11 +0200 Original-Received: (qmail 6603 invoked by uid 1000); 6 Sep 2023 11:29:11 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:310183 Archived-At: Hello, Arthur. On Wed, Sep 06, 2023 at 07:04:43 +0200, Arthur Miller wrote: > Richard Stallman writes: > > [[[ 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. ]]] > > > Would you please stop arguing for rewriting Emacs in Common Lisp? It > > > is a non-starter. > > > It would be an enormouse job -- including rewriting the Emacs Lisp > > > Referance Manual. > > Also, there are aspects of Common Lisp which i rejected as clumsy and > With all respect to you, but sound to me like an emotional argument, not > a rational one. It's a rational argument expressed in emotional terms for simplicity. > I don't know why you reject them as clumsy, but why does it matter to us > if a tool includes features we don't use? It matters a very great deal. In practice you cannot avoid "using" these features if you have to understand or debug somebody else's code. > I don't know if I understand it correctly, but CL was made so other > Lisps can be abstracted on top of it; so we use those features to > abstract stuff on top of those lengthy verbose functions? In other > words we can hide those keyword params behind elispy abstractions if we > don't like them? That's complexity and bloat. Far better not to have them in the first place. > > best avoided. > Why are they best avoided? Is there some technical reason or is it > psychological? It's because they are not needed. Bear in mind, Common Lisp is a massive language, much like C++ or PL/1 or Algol-68. With such a language, nobody uses all of it (it's just too big), but everybody has her own personal subset. This creates difficulty when somebody else has to understand that first hacker's code. CL is a niche language; it has not captured the hacker mindset. I think it is just too big and too unwieldy. > > best avoided. All those keyword arguments! I intentionally excluded > > tham from Emacs and I am not going to let them in. > I don't want to be impolite, but they are already in; via cl-lib.el. Yes. There was a time not so long ago when cl.el was banned from use in our Lisp code, except for at compile time. Our Emacs Lisp was small, simple to understand, and easy to learn. Now things in cl-lib.el get used as if they are just a normal part of Emacs Lisp. Our language is thus MUCH more difficult to understand, perhaps by a factor of somewhere between 3 and 10. When perusing even established parts of Emacs I groan inwardly every time I encounter one of these needless cl-lib features. It stops me dead, forcing me to consult doc strings (which are often missing and often inadequate even when they are present) or even manuals. Were we to rewrite Emacs in Common Lisp, these things would get worse fairly quickly. -- Alan Mackenzie (Nuremberg, Germany).