From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 15:55:35 +0200 Message-ID: <8738bquzag.fsf@fencepost.gnu.org> References: <87wq97i78i.fsf@earlgrey.lan> <87sijrv6v9.fsf@fencepost.gnu.org> <87zjdzw4tq.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1410962612 32173 80.91.229.3 (17 Sep 2014 14:03:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 14:03:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Mark H Weaver Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 16:03:27 2014 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 1XUFpN-0001d9-0c for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 16:03:25 +0200 Original-Received: from localhost ([::1]:45242 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFpM-00012r-Hm for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 10:03:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFpI-00012k-8Y for emacs-devel@gnu.org; Wed, 17 Sep 2014 10:03:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUFpE-0008IR-Ht for emacs-devel@gnu.org; Wed, 17 Sep 2014 10:03:20 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:54093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFpE-0008HI-Ey for emacs-devel@gnu.org; Wed, 17 Sep 2014 10:03:16 -0400 Original-Received: from localhost ([127.0.0.1]:59719 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFpA-0000iV-PM; Wed, 17 Sep 2014 10:03:13 -0400 Original-Received: by lola (Postfix, from userid 1000) id 1CD15E05E5; Wed, 17 Sep 2014 15:55:35 +0200 (CEST) In-Reply-To: <87zjdzw4tq.fsf@netris.org> (Mark H. Weaver's message of "Tue, 16 Sep 2014 18:58:25 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.10 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:174426 Archived-At: Mark H Weaver writes: > David Kastrup writes: > >> Bug report about basic list functionality not working for lists of more >> than 10009 members: >> >> > > One of our procedures has a scalability problem. Summarizing this as > "basic list functionality not working for lists of more than 10009 > members" is a gross misrepresentation. It's "drop-right" in srfi-1, the basic list processing library. 10009 is a typo, it's actually somewhere between 1000 and 10000 that GUILE bombs out. drop-right is basic enough that it is used in the implementation of reduce-right, propagating the scalability problem. I don't see it as a gross misrepresentation, but haggling about that would be missing the point anyway. > I responded within a day or so, and we had a conversation over the next > few days, but quickly ran into the problem that you wanted to change one > of our other API procedures in a non-standard way The "non-standard way" being the exact behavior of the Scheme reference implementation for srfi-1. > that conflicts with our existing behavior, and you simply wouldn't > take "no" for an answer. I gave up on this problem after pointing out that I saw no sensible solution within the restrictions you wanted to see implemented and I=A0pointed that out. At any rate, all this is missing the point. The point was that GUILE is not a vibrant project at a scale that can comfortably absorb the impact of becoming Emacs' main Lisp engine. Becoming Emacs' main Lisp engine will require timely answers to limitations in the VM, compilers, library routines, and Scheme standard interpretation that turn out to affect Emacs operations and Lisp implementations. In particular, it will not be an option to flag errors for every operation that has no well-defined semantics in Scheme when the corresponding operation in Common Lisp or Elisp happens to be well-defined and needed. And parting ways again in case the cooperation turns out bad is entirely different from parting ways with Bazaar, since we are talking about replacing Emacs' internals here rather than an external tool. So the situation with GUILE-Emacs more or less can be characterized as: you can check it in any time you want but you can never leave it. >> is an >> example for the inability to compile large expressions on Guile-2.0. >> The basic resume for this bug is "large expressions like that will >> only work with Guile-2.2+" > > Is it really a show-stopper that Guile 2.0 has limitations in the > sizes of some expression types? Semantic compiles grammars into code. "some expression types" in that bug report is a large "cond" statement, exactly the kind of thing a typical action-annotated grammar will be compiled into by a parser generator. GUILE compiles a cond statement into nested if statements. The VM does not offer any other renditions of conditionals, so _every_ way of expressing this function in terms of an open-coded block of code rather than, say, tables containing closures, will fail compilation. Yes, this can turn into sort of a scalability problem in my book. And Emacs is big. > Even C has similar limitations, and yet somehow it seems to be > successful. C restricts the number of cases in a switch statement (which would be the rough equivalent here)? That's news to me. --=20 David Kastrup