From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: David Kastrup <dak@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: Emacs Lisp's future
Date: Thu, 18 Sep 2014 11:27:22 +0200
Message-ID: <87egv9s2h1.fsf@fencepost.gnu.org>
References: <87wq97i78i.fsf@earlgrey.lan>
	<jwviokn4n6w.fsf-monnier+emacs@gnu.org>
	<87sijqxzr2.fsf@newcastle.ac.uk>
	<jwviokme7wa.fsf-monnier+emacs@gnu.org> <878uliwajb.fsf@taylan.uni.cx>
	<87lhpitg6t.fsf@fencepost.gnu.org> <87wq92uhwh.fsf@taylan.uni.cx>
	<541A0E71.6040703@dancol.org> <871tr9ty6l.fsf@fencepost.gnu.org>
	<87sijpuwn8.fsf@taylan.uni.cx>
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: ger.gmane.org 1411032471 12067 80.91.229.3 (18 Sep 2014 09:27:51 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Thu, 18 Sep 2014 09:27:51 +0000 (UTC)
Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
To: Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 18 11:27:44 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 1XUY08-0008UJ-4q
	for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 11:27:44 +0200
Original-Received: from localhost ([::1]:49301 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 1XUY07-0006c4-Kq
	for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 05:27:43 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47906)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <dak@gnu.org>)
	id 1XUXzt-0006bz-Ms
	for emacs-devel@gnu.org; Thu, 18 Sep 2014 05:27:31 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dak@gnu.org>) id 1XUXzs-0000CR-Al
	for emacs-devel@gnu.org; Thu, 18 Sep 2014 05:27:29 -0400
Original-Received: from fencepost.gnu.org ([208.118.235.10]:44834)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <dak@gnu.org>)
	id 1XUXzs-0000Bq-7Y
	for emacs-devel@gnu.org; Thu, 18 Sep 2014 05:27:28 -0400
Original-Received: from localhost ([127.0.0.1]:50463 helo=lola)
	by fencepost.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dak@gnu.org>)
	id 1XUXzm-0007Rn-EV; Thu, 18 Sep 2014 05:27:22 -0400
Original-Received: by lola (Postfix, from userid 1000)
	id 07A4FE07B0; Thu, 18 Sep 2014 11:27:22 +0200 (CEST)
In-Reply-To: <87sijpuwn8.fsf@taylan.uni.cx> (Taylan Ulrich Bayirli's message
	of "Thu, 18 Sep 2014 11:04:59 +0200")
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." <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:174489
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/174489>

Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Of course, that glosses over the fact that the end of a list may well
>> be implicitly checked for by using sentinels and other quite
>> legitimate programming practices.
>>
>> For example, two proper lists generally have a common tail, even if
>> that tail is only '(), and finding that tail is done by trimming the
>> longer list to the size of the shorter one and then cdr-ing the
>> remaining lists in synch until arriving at a matching value.
>>
>> Using "equal" for that comparison is not an option, and using "eq" is
>> no longer guaranteed to terminate without error.  The solution is to
>> declare the algorithm not well-written.
>
> So the problem is that two same-length lists are normally guaranteed to
> have an `eq' element at some point in Lisps, and Guile breaks this
> guarantee.  That seems like a legitimate concern; thanks for bringing it
> up.
>
> Fortunately, making use of this should be relatively rare, and the fix
> is relatively simple too.
>
> (In the algorithm you mentioned, the naive solution is to do an
> additional (and (null list1-rest) (null list2-rest)) at each cdr instead
> of only an (eq list1-rest list2-rest), and the smart solution to
> canonicalize the null objects at the ends during the length
> calculation/truncation which will inevitably visit the ends of both
> lists, if the algorithm needs to be as efficient as possible.)

Well, as I said: the solution is to declare the algorithm not
well-written.

> Considering also that the issue will only arise during inter-operation
> of the languages, which should be limited to rare situations like
> internal Scheme code raising an error that's handled in Elisp, the
> combined chance of this issue ever hitting a pure Elisp user seems
> minuscule.

That is under the premise that Emacs will not be extended in _any_
language except Elisp.

So that leaves us with one of two conclusions: the advertisement of
ultimately being able to extend Emacs in multiple languages possibly
including Scheme, JavaScript and Lua is not going anywhere, or existing
Elisp code will generally need to be revised in order to work in an
Emacs running extensions written in other languages.

For example, GUILE prouds itself of including an LALR(1) parser
generator running native Scheme code.  Using it for semantic parsing in
Emacs will not be feasible if its "Scheme data model" is incompatible
with the "Elisp data model".

> All in all, it's not a concern for Emacs users who don't mess with
> Scheme, and quite a small one for those who do.

But the whole point of the exercise was to enable messing with Scheme.

-- 
David Kastrup