From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 11:19:53 -0400 Message-ID: <87egvap945.fsf@yeeloong.lan> References: <87wq97i78i.fsf@earlgrey.lan> <87sijrv6v9.fsf@fencepost.gnu.org> <87zjdzw4tq.fsf@netris.org> <8738bquzag.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410974098 841 80.91.229.3 (17 Sep 2014 17:14:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 17:14:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 19:14:52 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 1XUIoe-0003E9-1n for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 19:14:52 +0200 Original-Received: from localhost ([::1]:46446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIod-000836-KJ for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 13:14:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUH3K-0004Wv-Ss for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:21:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUH3G-0006UA-3J for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:21:54 -0400 Original-Received: from world.peace.net ([96.39.62.75]:46680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUH3F-0006Tx-Vq; Wed, 17 Sep 2014 11:21:50 -0400 Original-Received: from c-24-62-95-23.hsd1.ma.comcast.net ([24.62.95.23] helo=yeeloong.lan) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XUH30-0001EQ-Nn; Wed, 17 Sep 2014 11:21:34 -0400 In-Reply-To: <8738bquzag.fsf@fencepost.gnu.org> (David Kastrup's message of "Wed, 17 Sep 2014 15:55:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-Mailman-Approved-At: Wed, 17 Sep 2014 13:14:30 -0400 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:174448 Archived-At: David Kastrup writes: > Mark H Weaver writes: > >> 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. *sigh*, must we repeat our discussion here on emacs-devel, when it's already in the bug tracker at http://bugs.gnu.org/17296 ? To summarize: the spec says it's an error to pass 'length+' an improper list. Guile has always returned #f in that case, and existing code may depend on that. You want to change it to return the number of pairs in the improper list. Yes, that's what the reference implementation does. I think it's too risky to change Guile's behavior in this case from one non-error to another non-error, because existing code may silently start misbehaving, and it would also cause things like (map + - * /) to return () without reporting any error. If you want to continue this discussion about 'length+', can you please respond to my last message at http://bugs.gnu.org/17296 instead of here? >> 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. 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. See http://wingolog.org/archives/2014/03/17/stack-overflow for more. Mark