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 18:23:01 +0200 Message-ID: <87ha06tdwa.fsf@fencepost.gnu.org> References: <87wq97i78i.fsf@earlgrey.lan> <87sijrv6v9.fsf@fencepost.gnu.org> <87zjdzw4tq.fsf@netris.org> <8738bquzag.fsf@fencepost.gnu.org> <87egvap945.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1410971864 1603 80.91.229.3 (17 Sep 2014 16:37:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 16:37:44 +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 18:37:40 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 1XUIEd-0006CC-IT for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 18:37:39 +0200 Original-Received: from localhost ([::1]:46255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIEd-0005pl-5X for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 12:37:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIEK-0005oY-RI for emacs-devel@gnu.org; Wed, 17 Sep 2014 12:37:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUIEH-0002RC-9W for emacs-devel@gnu.org; Wed, 17 Sep 2014 12:37:20 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIEH-0002Q0-6f for emacs-devel@gnu.org; Wed, 17 Sep 2014 12:37:17 -0400 Original-Received: from localhost ([127.0.0.1]:34597 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUI0U-0002JK-7m; Wed, 17 Sep 2014 12:23:02 -0400 Original-Received: by lola (Postfix, from userid 1000) id 91F23E05E5; Wed, 17 Sep 2014 18:23:01 +0200 (CEST) In-Reply-To: <87egvap945.fsf@yeeloong.lan> (Mark H. Weaver's message of "Wed, 17 Sep 2014 11:19:53 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:174444 Archived-At: Mark H Weaver writes: > David Kastrup writes: > >> Mark H Weaver writes: >> >>> Is it really a show-stopper that Guile 2.0 has limitations in the >>> sizes of some expression types? > [...] >> Yes, this can turn into sort of a scalability problem in my book. And >> Emacs is big. > > The problem is fixed on the master branch, which is the only branch > that supports guile-emacs anyway. Ok, so guile-emacs will not work with the "stable" branch. If I take a look at the "master" branch which is the only one supporting guile-emacs, I see things like commit 2c02a21023c946a3d31c43417d440d6babbf2622 Author: Andy Wingo Date: Sun Jun 29 14:29:20 2014 +0200 Remove namesets. This was a failed experiment. It had good space complexity but ter= rible time complexity. * module/Makefile.am: Update. * module/language/cps/nameset.scm: Remove. [...] commit ec412d75627aeffbd816ac351eabcd1b533540c6 Author: Andy Wingo Date: Thu Jun 19 08:49:05 2014 +0200 Rewrite type inference pass to use namesets * module/Makefile.am: Build types.scm early, but don't block the re= st of the build on it. * module/language/cps/types.scm: Rewrite to use namesets. * module/language/cps/dce.scm: * module/language/cps/type-fold.scm: Adapt to interface changes. commit 97ed2e77ab22e1695c5c4df6f5f6cfd98b90636f Author: Andy Wingo Date: Sun Jun 8 18:50:07 2014 +0200 New module: (language cps nameset) * module/language/cps/nameset.scm: New file. * module/Makefile.am: Add new file. which make clear that the master branch in GUILE is _highly_ experimental. If you take a look at the GUILE developer list archives at and previous months, you'll find that Andy Wingo does not participate in any discussions there. So basically GUILE master is his private playground which he works on in bursts of activity without publicly visible communication. I don't see that basing Emacs on that kind of setup is remotely realistic without serious reorganization of how GUILE organizes and views its development processes. Emacs is a remarkably _stable_ and reliable piece of software considering its size and age. > So, why are limitations in Guile 2.0 relevant for guile-emacs? > > Incidentally, the 'drop-right' scalability problem you complain above > above is also fixed on the master branch, and plenty of others. The > reason is that our stacks are now automatically expanded as needed, > limited only by the available memory, so we can now write recursive > procedures in a natural way without ugly hacks to make them scalable. Personally, I don't consider automatically expanding stack size a "solution" to a routine unnecessarily shoving all elements of an arbitrarily large data structure interspersed with return addresses onto a VM stack before processing it. But then tastes may differ. I=A0started programming at a time when I paid the equivalent of =A4400 for 64kB of RAM, so throwing RAM at a problem was expensive enough to be habit forming. > See http://wingolog.org/archives/2014/03/17/stack-overflow for more. At any rate, this is again a distraction. The topic is how suitable GUILE is for turning into the Lisp foundation of Emacs. And I think that apart from reestablishing that I am a dishonest manipulative asshole who does not know what he is talking about, we got some insights into the current state of GUILE development that may help in refining goals and obstacles in the process of making GUILE the Lisp implementation underlying Emacs. --=20 David Kastrup