Re: String Literals, take 3

John Williams wrote:

>On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
>  
>
>>John Williams wrote:
>>    
>>
>>>On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
>>>      
>>>
>>>>With all of the new crazy quoting shenanagains, I'm not sure that the
>>>>"balenced brackets are fine" rule will still be possible; and thus end
>>>>delimeters will always need to be escaped.  For instance, imagine
>>>>what a nightmare this would be to parse:
>>>>
>>>>$var = qq[blah [\q[blah [\qq[%hash{qq[[hi]]}]]]] blah];
>>>>
>>>>Sure, anyone who writes something like this deserves to be shot;
>>>>however, if the "balanced brackets are ok" rule still stands, the
>>>>above code would be legal.  (And I really, really, really don't
>>>>want the above code to be legal ;)
>>>>        
>>>>
>>>Well, just don't do it then.  With or without balanced brackets, the
>>>obfuscating programmer can do the above; he just needs more or less
>>>backslashes.
>>>      
>>>
>>Saying "Just don't do it" doesn't stop someone from doing it.  True,
>>the example was an obfuscated one, but it was to prove a point.  This is
>>just as obfuscated in my opinion:
>>
>>$var = qq[[[%hash{qq[one]}{qq[next]}],[],[%hash{qq[hi]}{qq[there]}]]];
>>
>>Adding backslashes to the first example helps clear up some of the
>>confusion:
>>
>>$var = qq[blah [\q[blah [\qq[%hash{qq[[hi\]]}]\]]\]blah];
>>$var = qq[blah \[\q[blah \[\qq[%hash{qq[\[hi\]]}]\]]\]blah];
>>    
>>
>
>Maybe that's because you wrote it in the first place; as a reader I think
>it looks just as bad, if not worse.
>

True, it looks *very* bad, but least its easier to tell what
quotes and what doesn't.

>>Really, I think that if you really feel the need to use a delimiter
>>that you know that will be in the text that you are quoting, you should
>>have to go through the trouble of escaping it.  Its only fair :)
>>    
>>
>
>No, it's not fair, because I ALWAYS have to worry about escaping
>something.  What I really want is a quote operator which really quotes
>everything.  I don't want to have to worry about what accidental "\q"
>substrings are going to do in my strings.  q{} was the best way to do that
>in perl5, because even braces within the string were ok if they behaved
>themselves.
>  
>

What's wrong with single quoted here-docs?

>>>'\qq[]' is the real source of evil here.
>>>
>>>Actually the apocalypse says:
>>>
>>>      
>>>
>>>>RFC 226: Selective Interpolation in Single Quotish Context.
>>>>
>>>>This proposal has much going for it, but there are also difficulties,
>>>>and I've come close to rejecting it outright simply because the
>>>>single-quoting policy of Perl 5 has been successful.
>>>>        
>>>>
>>>Maybe if we pushed Larry a bit, he could reject it after all?
>>>      
>>>
>>Why?  I love \qq[] and \q[].  I'd much rather have embedded strings
>>than be able to balance used delimiters inside quotes.  I don't like the
>>"balance delimeters" rule at all, and don't see it as anything more
>>than an ugly hack.  I'd much rather have it go than embedded strings.
>>    
>>
>
>I am diametrically opposed to your opinions here.  I hate '\qq[]' as an
>ugly hack, which ruins the non-embedding, non-quoting nature of
>non-interpolated strings.  If you want to embed, just use interpolated
>strings.
>

Don't forget that the backslash is already special in
non-interpolating strings; I don't think that adding a single
special case will make things too confusing.

>What if \q[] was allowed in interpolated strings, but not in
>non-interpolated strings.  Then I'm happy with that non-interpolated
>strings really don't interpolate, and you might be happy because it would
>only make sense to do one level of nesting. ie, you cannot embed \qq[]
>inside \q[].  Or you could do $(''), which is the same number of
>characters as \qq[], and doesn't require introducing
>yet-another-new-rule-to-an-already-too-complicated-escaping-system.
>

I think \qq[] is the much more useful of the two, so
that really doesn't help much.


Joseph F. Ryan
[email protected]