From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Mark H Weaver <mhw@netris.org>
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>
	<jwviokn4n6w.fsf-monnier+emacs@gnu.org>
	<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 <dak@gnu.org>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 19:14:52 2014
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	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 <mhw@netris.org>) 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 <mhw@netris.org>) 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 <mhw@netris.org>)
	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 <mhw@netris.org>)
	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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=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: <http://permalink.gmane.org/gmane.emacs.devel/174448>

David Kastrup <dak@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> 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