On Wed, Jul 21, 2004 at 12:36:51PM -0600, Luke Palmer wrote:
: Brent 'Dax' Royal-Gordon writes:
: > The equivalent regex syntax isn't interpolating, even to the extent that
: > a bare $foo or @bar is, so this would be sort of a "false cognate"--IMHO
: > another reason not to have interpolating {}.
:
: Yeah, I agree with you. I was stretching big time to find the merit in
: the idea.
Well, I don't think that's the important distinction. In each case
it's a closure that is evaluated at the appropriate point in time.
It's only the results of that closure that differ based on context,
and that's only to be expected. In terms of result, "{...}" is more
like /<{...}>/, I suppose.
: I suppose another good thing is that it makes unneccesary the balanced
: brace rule in qq{} that was there in Perl 5: all braces need to be
: backwhacked now. However, all braces need to be backwhacked now. Ugh.
Not really. Trailing braces need to be backwhacked only if the
initial ones are. Something to be said for symmetry...
: > >>and what about "@a[1]('arg')[3]"?
: > >
: > >That probably wouldn't.
: >
: > Actually, I have to wonder why &foo('bar', 'baz') wasn't on Larry's
: > list. Is there a reason for that?
:
: Probably because &foo('bar', 'baz') isn't a function call. All that
: does is refer to a function &foo with a siglet ('bar','baz'), which
: means either nothing or a syntax error. The function call looks like
: foo('bar', 'baz');
Well, actually, lately &foo('bar','baz') has mutated back into being
a function call, on the theory that C<&foo> consistently produces a
reference and C<.()> consistently dereferences it. We only made the
non-call-rule of & earlier because we wanted to have signatures like
&foo(int,num)
but we later changed parametric type arguments to use square brackets,
and at the same time changed signatures to use
&foo[int,num]
So now there's no ambiguity with letting &foo(...) make a call.
Larry
