Re: RFC 110 (v3) counting matches

>>>p.s. Has anybody already suggested that we ought to have a nicer
>>>solution to execute perl code inside a string, replacing "${\(...)}" and
>>>"@{[...]}", which also won't ever win a beauty contest?  Oops, wrong
>>>mailing list.
>>
>>The first one doesn't work, and never did.  You want 
>>@{[....]} and @{[scalar ....]} instead.

>"Doesn't work"?

>	print "The sum of 1 + 2 is ${\(1+2)}.\n";
>-->
>	The sum of 1 + 2 is 3.

>I'm surprised your wouldn't have known this. The principle is the same:
>"${...}" expects a scalar reference inside the block, and '\' provides
>one. Of course, there shouldn't be a real multi-element list inside the
>parens, but just one scalar. And often, the parens aren't needed.

I'm surprised that you still don't understand.  Notice what I showed
you for the replacement above: @{[scalar ....]}.

Using ${\(...)} doesn't work in the sense that contrary to popular
belief, it fails to provide a scalar context to the contents of
those parens.  Thus ${ \( fn() ) } is still calling fn() in list
context, not scalar context.  Witness:

    sub fn { sprintf "called in %s context", wantarray ? "list" : "scalar" } 

    print "Test 1: ";
    print "@{ [fn()] }\n";

    print "Test 2: ";
    print "${ \(fn()) }\n";

    print "Test 3: ";
    print "@{ [scalar fn()] }\n";

That, when executed, yields:

    Test 1: called in list context
    Test 2: called in list context
    Test 3: called in scalar context

*That's* why test 2 "doesn't work".

--tom