From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Matthew Plant Newsgroups: gmane.emacs.devel Subject: Re: Raw string literals in Emacs lisp. Date: Tue, 29 Jul 2014 17:26:01 -0700 Message-ID: References: <878ungor1v.fsf@uwakimon.sk.tsukuba.ac.jp> <8761ijng08.fsf@uwakimon.sk.tsukuba.ac.jp> <871tt7lzro.fsf@fencepost.gnu.org> <53D567FD.4030708@porkrind.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b34340c6a75ef04ff5e3323 X-Trace: ger.gmane.org 1406679988 4375 80.91.229.3 (30 Jul 2014 00:26:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jul 2014 00:26:28 +0000 (UTC) Cc: "emacs-devel@gnu.org" , David Caldwell To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 30 02:26:20 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 1XCHil-0003BV-Gb for ged-emacs-devel@m.gmane.org; Wed, 30 Jul 2014 02:26:19 +0200 Original-Received: from localhost ([::1]:48452 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCHik-00019O-IJ for ged-emacs-devel@m.gmane.org; Tue, 29 Jul 2014 20:26:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCHib-00017Y-Nx for emacs-devel@gnu.org; Tue, 29 Jul 2014 20:26:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCHiV-00062G-I5 for emacs-devel@gnu.org; Tue, 29 Jul 2014 20:26:09 -0400 Original-Received: from mail-lb0-f174.google.com ([209.85.217.174]:53587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCHiV-000617-BV for emacs-devel@gnu.org; Tue, 29 Jul 2014 20:26:03 -0400 Original-Received: by mail-lb0-f174.google.com with SMTP id c11so316045lbj.33 for ; Tue, 29 Jul 2014 17:26:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nd77zMGbv2LncVMrxAkjhWUpjifn71oDDM4HO80yIgU=; b=F1jLBM3DBFfaoqRRxYdfnC3Oyul8KFkSwDUwJluYsuiNp+oqe4DgdjSLEeIP4rALPM b9f8TosUluvSqTxTGX136Vd4zksJvK9oGVRJ7B96q6ngeUtsRH1iIR50lhrq1+3Q2TJy HKlNXxApb1YiIagqZl8y4QHUL4mPBsAQTuNlTWSb7pQJ8D8bCctTnZcAaQO+gwKgGP85 QrZnjNOlP4kvT3FTjCNDvtHc/eeq2YJiuBrP0WB4rh9d3WQ+s6CJ971olVutqhU7iqns WV8M6VApYn6bhppQnUvH22PiT1mmMPqcltx6JQ3B5jQFnQdvedSQPnQb4yjuaBNcrcTK TBOQ== X-Gm-Message-State: ALoCoQlxTKs1hZAs7lvGktf6Xt5n8yIDIKyg8t4uEVdEG33bfqtmHd5q+mjjN30vnQNPkXGjU1Nu X-Received: by 10.112.150.106 with SMTP id uh10mr411666lbb.11.1406679961461; Tue, 29 Jul 2014 17:26:01 -0700 (PDT) Original-Received: by 10.112.185.99 with HTTP; Tue, 29 Jul 2014 17:26:01 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.217.174 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:173273 Archived-At: --047d7b34340c6a75ef04ff5e3323 Content-Type: text/plain; charset=UTF-8 If it can be parsed forwards it can be parsed backwards, although it might not be immediately possible to do so. The parser might have to check to see if it needs to re-parse a section, but I don't think there's any syntax we could introduce that is impossible to parse backwards. It's a difficulty thing. However, a regex syntax would be much more difficult to parse backwards; I think this is a convincing enough argument that only simple raw strings should be implemented. Pretty much every modern language that has regex has raw string literals. Heck, when regex was added to the C++ standard, raw string literals where added in the same spec. If raw string literals were added, should they allow custom delimiters? This would probably make the strings just as hard to parse backwards as regexps, so I say no. --047d7b34340c6a75ef04ff5e3323 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If it can be parsed forwards it c= an be parsed backwards, although it might not be immediately possible to do= so. The parser might have to check to see if it needs to re-parse a sectio= n, but I don't think there's any syntax we could introduce that is = impossible to parse backwards. It's a difficulty thing.

However, a regex syntax would be much more difficult t= o parse backwards; I think this is a convincing enough argument that only s= imple raw strings should be implemented.

Pretty much every mod= ern language that has regex has raw string literals. Heck, when regex was a= dded to the C++ standard, raw string literals where added in the same spec.=

If raw string literals were added, should they allow custom delim= iters? This would probably make the strings just as hard to parse backwards= as regexps, so I say no.
--047d7b34340c6a75ef04ff5e3323--