Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: multi-line Strings Date: Tue, 11 Dec 2012 22:44:48 +0000 (UTC) Organization: UK Free Software Network Lines: 42 Message-ID: References: <7f36342c-2331-4484-874b-4a0f8953f160@googlegroups.com> <50c61150$0$293$14726298@news.sunsite.dk> <50c6413a$0$293$14726298@news.sunsite.dk> <50c6598d$0$290$14726298@news.sunsite.dk> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1355265888 6431 84.45.235.129 (11 Dec 2012 22:44:48 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Tue, 11 Dec 2012 22:44:48 +0000 (UTC) User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Xref: csiph.com comp.lang.java.programmer:20263 On Tue, 11 Dec 2012 10:43:49 -0600, Joshua Cranmer wrote: > On 12/10/2012 6:17 PM, Martin Gregorie wrote: >> On Mon, 10 Dec 2012 18:04:33 -0500, Eric Sosman wrote: >> >> >>> It's unfortunate that both Java and regex use \ so heavily, >>> because it leads to a lot of escaping-of-escapes and harms >>> readability. But why should it be a given that Java's literals should >>> be different to avoid conflict with regex syntax? Why not change the >>> regex syntax instead, and use, say, ~ for the role now taken by \? It >>> might improve regexes to the point where they're merely unreadable, >>> instead of intolerable. ;-) >> >> I've always liked the Awk and Perl default convention of delimiting >> regexes with slashes: /regex/ - if their compilers can deal with this >> cleanly, the Java compiler could surely do the same. > > Which works really well until you want to match the / character in > pathnames. Or you want to lex but not parse the language--note that > /foo/ is lexed as a regex if the preceding token is an operator and > lexed as a sequence of tokens (DIV, IDENT, DIV) if the preceding token > is an operator. > So its context sensitive. It that really a huge issue? In practice you'll almost never see a regex in Java that isn't a method's argument because of the way the regex package was designed. That means you'd be in 'parameter context' when parsing it. I can see there'd be issues with something like Perl's 'm' syntax, but straight /regex/ notation should not be hard to deal with. If you're piecing a regex together StringBuilder, again you'd be in 'parameter context' though I grant that if you're trying to build a regex by concatenating strings with '+' you may have a problem. But, lets face it, doing that is likely to be an unreadable mess no matter what syntactic sugar gets sprinkled on it. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |