Brad Bowman wrote: > Jonathan Lang wrote: > > Let me see if I understand this correctly: Instead of interpolation > > being enabled by default with backwhacks selectively disabling it, you > > want something where interpolation is disabled by default with > > "anti-backwhacks" selectively enabling it. Right? > > Not speaking for Piers... > > Something like that, although trying to find universal anti-backwhacks > in the strings handled by Perl is much harder than finding meta-syntax > for S-expressions. That's why I was suggesting a mechanism to selectively > enable interpolation by name rather than syntax.
I don't see why you'd need a universal anti-backwhack, any more than you need universal quote delimiters. I could see introducing an adverb to the quoting mechanism that lets you define a custom backwhack character in qq strings (for those rare cases where literal backslashes are common occurrences), and then press the same adverb into service in q strings to define a custom anti-backwhack. The only difference is that there's a default backwhack character (the backslash), but there is no default anti-backwhack. So: my $code = q:interp(`){ package `$package_name; sub `$sub_name { `$the_complex_value_we_want_to_use_in_generated_code } sub `$another_sub_name { [EMAIL PROTECTED](';')} } }; I'd go so far as to say that the anti-backwhack would only have a special meaning in front of a $, @, %, {, \, or another anti-backwhack; in all other cases, it gets treated as a literal character just like anything else. There may be some edge conditions that I haven't thought of; but I think that this is a decent baseline to work from. I think the Huffman encoding is correct on this, up to and including the length of the adverb needed to define a custom backwhack or anti-backwhack. -- Jonathan "Dataweaver" Lang