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
