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: Thu, 18 Sep 2014 11:27:22 +0200 Message-ID: <87egv9s2h1.fsf@fencepost.gnu.org> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <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 , emacs-devel@gnu.org To: Taylan Ulrich Bayirli/Kammer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 18 11:27:44 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 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 ) 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 ) 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 ) 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 ) 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 ) 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." 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:174489 Archived-At: Taylan Ulrich Bayirli/Kammer writes: > David Kastrup 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