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
