From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Taylan Ulrich Bayirli/Kammer Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Thu, 18 Sep 2014 11:04:59 +0200 Message-ID: <87sijpuwn8.fsf@taylan.uni.cx> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411031539 31280 80.91.229.3 (18 Sep 2014 09:12:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Sep 2014 09:12:19 +0000 (UTC) Cc: Daniel Colascione , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 18 11:12:12 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 1XUXl6-00034x-5w for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 11:12:12 +0200 Original-Received: from localhost ([::1]:49228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUXl5-0002De-IC for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 05:12:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUXkr-0002DZ-RY for emacs-devel@gnu.org; Thu, 18 Sep 2014 05:11:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUXkq-0004MK-F7 for emacs-devel@gnu.org; Thu, 18 Sep 2014 05:11:57 -0400 Original-Received: from mail-lb0-x22f.google.com ([2a00:1450:4010:c04::22f]:43395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUXkq-0004Kl-6R; Thu, 18 Sep 2014 05:11:56 -0400 Original-Received: by mail-lb0-f175.google.com with SMTP id n15so705571lbi.6 for ; Thu, 18 Sep 2014 02:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=6tZoH/AzCOQzSn5O9AybIuWUQ/W02XBaG22grSNJXOo=; b=LGh3t06nZXEY09/SPnwMVpu1wfIluFLxfe1bEJ5uP5+P91RESm4uAEV54XegjPmSSx n6Lht1+8vYmQOryF8aLVO31Nb+IykzbekV7BCxlghaRnbJDSGKtKBOdFBeiMTs1r/PGO I+sejxALnTex5FifQpLmw155IzbCTVDtJ9k3nVYIP7C7SB2mJ7RD9bJTP9Gs4+GH9soM BGDZxgsd0GvO+n5DgxCLnoVkKAcyF2lTTV5DoQaooBYVVMXdSlCME+NKWrmtSdw1BrSk FOBNT0Cst96j/HEooguatfW4M+YrINOXoMJQwTgJNiLk4CbNpDQnvoWsWhd1MTakB3aI GTPQ== X-Received: by 10.152.9.37 with SMTP id w5mr3378325laa.28.1411031102692; Thu, 18 Sep 2014 02:05:02 -0700 (PDT) Original-Received: from taylan.uni.cx (p200300514A48ABEE0213E8FFFEED36FB.dip0.t-ipconnect.de. [2003:51:4a48:abee:213:e8ff:feed:36fb]) by mx.google.com with ESMTPSA id nx9sm6101280lbb.23.2014.09.18.02.05.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Sep 2014 02:05:02 -0700 (PDT) In-Reply-To: <871tr9ty6l.fsf@fencepost.gnu.org> (David Kastrup's message of "Thu, 18 Sep 2014 05:17:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22f 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:174488 Archived-At: 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.) 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. 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. Taylan