From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Why (substring "abc" 0 4) does not return "abc" instead of an error? Date: Mon, 16 Jul 2012 19:57:15 +0200 Message-ID: <874np7h9ms.fsf@thinkpad.tsdh.de> References: <87fw8smxag.fsf@gnu.org> <877gu4mv85.fsf@gnu.org> <871ukcmb47.fsf@gnu.org> <87hat7bqmh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1342461452 6720 80.91.229.3 (16 Jul 2012 17:57:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2012 17:57:32 +0000 (UTC) Cc: Juanma Barranquero , Stefan Monnier , emacs-devel@gnu.org To: Bastien Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 16 19:57:29 2012 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 1SqpY1-0005AP-JE for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2012 19:57:29 +0200 Original-Received: from localhost ([::1]:47810 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqpY0-0003Zt-Pe for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2012 13:57:28 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqpXu-0003ZZ-EC for emacs-devel@gnu.org; Mon, 16 Jul 2012 13:57:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SqpXt-0005kd-CN for emacs-devel@gnu.org; Mon, 16 Jul 2012 13:57:22 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:56854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqpXr-0005jo-Nr; Mon, 16 Jul 2012 13:57:19 -0400 Original-Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 07CEC20CA1; Mon, 16 Jul 2012 13:57:19 -0400 (EDT) Original-Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 16 Jul 2012 13:57:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:to:cc:subject:references:date :in-reply-to:message-id:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=0iwFf/gPtvzb5igz7tDKzm 1gitw=; b=G/vEFSFFnS8dSmez8U65YYwGn6jl2fFe/A8nMoVYP9TUAGNeBNE5MT rsB8XUMkJ6YXaUob9o0mEY6Jy6lPHTwhc3fhmQ55sAvbZnmq+IZPGu0peOZ+GJAT S/xGVrpu7nrJhMupshI9ZToK4ToioPr5cBe97MxL/kg0sEF90u5sU= X-Sasl-enc: 5ZI5RLx2H+0d48uySksKT4V/VYZyA3yq/qlOt19WcmI1 1342461438 Original-Received: from thinkpad.tsdh.de (unknown [91.67.9.216]) by mail.messagingengine.com (Postfix) with ESMTPA id D08348E01DC; Mon, 16 Jul 2012 13:57:17 -0400 (EDT) In-Reply-To: <87hat7bqmh.fsf@gnu.org> (Bastien's message of "Mon, 16 Jul 2012 18:46:46 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.111.4.27 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:151681 Archived-At: Bastien writes: >> We have general functionality when you want to ignore some errors, >> such as condition-case. > > Also, I'm fine with > > (substring "abc" -1 1) > =3D> #ERROR I don't see why that justifies an error and (substring "abc" 0 4) does not. -1 is a valid FROM index meaning the length of the string minus one. Its just that the TO index is smaller than FROM here, but IMO that's the same class of errors as a too large TO index. > so using =CC=80condition-case' would not help me distinguish > between the case above and (substring "abc" 0 4), which > is what I want. A condition-case handler has access to the args given to the erroring form, so the cases could be distinguished although both signal args-of-range. Well, not that it would help you much here.=20=20 > I see the benefit of having=20 > > (substring "abc" 0 4) > =3D> "abc" > > in terms of simplifying Elisp writing -- and I still fail > to see the harm (but maybe Pascal will tell me where he has > been bitten by this.) In my experiences, out-of-range indices into strings or arrays are almost always programming errors. I'm not even able to come up with some concrete use-case where I'd like to have the suggested behavior. Either I know exactly what I'm operating on and use indices, or I have only some general assumptions and then use more fuzzy things like splitting by regular expressions. BTW: C++ string's substr method doesn't quite have the suggested behavior. It's arguments are not two indices, but one index and one length n (the number of characters that should be returned). If the index is out of range, you'll get an out_of_range exception. n however may span longer than the rest of the string in which case the returned string is shorter than the given length n. But that's a different story: indexes have to be in range. Ditto for Ruby: String::slice also gets an index and a length, not two indices. Bye, Tassilo