On Sat, Oct 07, 2006 at 03:07:49PM -0700, Jonathan Lang wrote: : S5 says: : >There is no /e evaluation modifier on substitutions; instead use: : > : > s/pattern/{ doit() }/ : > : >Instead of /ee say: : > : > s/pattern/{ eval doit() }/ : : In my perl5 code, I would occasionally take advantage of the "pairs of : brackets" quoting mechanism to do something along the lines of: : : s(pattern) { doit() }e : : Translating this to perl 6, I'm hoping that perl6 is smart enough to let me : say: : : s(pattern) { doit() }
Well, the () are illegal without intervening whitespace because that makes s() a function call, but we'll leave that alone. : Instead of : : s(pattern) { { doit() } } Perl 5 let certain choose-your-own quotes introduce various kinds of odd semantics, and that was generally viewed as a mistake. That is why S02 says: For these "q" forms the choice of delimiters has no influence on the semantics. That is, C<''>, C<"">, C<< <> >>, C<«»>, C<``>, C<()>, C<[]>, and C<{}> have no special significance when used in place of C<//> as delimiters. We could make an exception for the second part of s///, but certainly for this case I think it's easy enough to write: .subst(/pattern/, { doit }) However, taken as a macro, s/// is a rather odd fish. The right side isn't just a string, but a deferred string, which implies that there are always curlies there, much like the right side of && implies deferred evaluation. : In a similar vein, I tend to write other perl5 substitutions using : parentheses for the pattern so that I can use double-quotes for the : substitution expression: : : s(pattern) "expression" Because the right side must be deferred, the .subst form of that would be: .subst(/pattern/, {"expression"}) Otherwise, the double quotes interpolate too early. That's getting a little more cumbersome. : This highlights to me the fact that the expression is _not_ a pattern, : and uses a syntax more akin to interpolated strings than to patterns. : The above bit about executables got me to thinking: _if_ perl6 is : smart enough to recognize curly braces and automatically treat the : second argument as an executable expression, would there be any : benefit to letting perl6 apply customized quoting semantics to the : second argument as well, based on the choice of delimiters? e.g., : using single quotes would disable variable substitutions and the like : (useful in cases where the substitution doesn't make use of the : captures done by the pattern, if any). Well, again, that's maybe just: .subst(/pattern/, {'expression'}) or even, since we don't need to delay evaluation: .subst(/pattern/, 'expression') But it's possible that some syntactic relief of a dwimmy sort is in order here. One could view s[pattern] as a kind of metaprefix on the following expression, sort of a self-contained unary &&. I wonder how often we'd have to explain why s/pattern/ "expression" doesn't do that, though. 'Course, it's already like that in Perl 5. Unlike in Perl 5, this approach would rule out things like: s[pattern] !foo! which would instead have to be written: s[pattern] qq!foo! As a unary lazy prefix, you could even just say s[pattern] doit(); Of course, then people will wonder why .subst(/pattern/, doit()) doesn't work. Which makes me want to build it into the pattern somewhere where there's already deferred evaluation that just happens to be triggered at the right moment: /pattern {subst doit}/ /pattern {subst "($0)"}/ /pattern {subst q:to'END'}/ a new line END We can give the user even more rope to shoot themselves in the dark with: /pattern {$/ = doit}/ /pattern {$0 = "($0)"}/ /pattern {$() = q:to'END'}/ a new line END The possibilities are endless... Well, not quite. One syntax we *can't* allow is /pattern/{ doit } because that's already used to pull named captures out of the match object. Well, enough random braindump for now. Larry