develooper Front page | perl.perl5.porters | Postings from July 2012

Re: What would having a & prototype after the first position break?

Thread Previous | Thread Next
From:
demerphq
Date:
July 10, 2012 23:35
Subject:
Re: What would having a & prototype after the first position break?
Message ID:
CANgJU+VoOzx_zstps9atmVPLscm9=E2OpqYssDySrqJWRW3phw@mail.gmail.com
On 10 July 2012 15:41, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
> On Fri, Jul 06, 2012 at 12:13:51PM +0200, Paul Johnson wrote:
>> On Wed, Jul 04, 2012 at 12:58:21AM -0400, Chris Nehren wrote:
>> > Recently I've been working on a DSL of sorts that would be more
>> > succinctly expressed if I could have a prototype like ($&&). What would
>> > break if we allowed the & prototype after the first position? To make
>> > the proposed feature concrete, it would enable us to have syntax like
>> > (courtesy of LeoNerd):
>> >
>> > generic_sort { $a <=> $b } { length $_ } @strings;
>
> *grin*
>
>> > or (from my own code):
>> >
>> > loop host 'shadowcat' => { do_stuff; };
>> >
>> > I'm fine with doing the work to add this feature. I would just like to
>> > be sure I don't break half of CPAN with my efforts.
>> >
>> > Thoughts? Comments? Rallying praise? Rotten tomatoes?
>
> Needless to say, I'd be quite keen to get this ability...
>
>> My recent rjbs induced trip down memory lane unearthed the following
>> message from a certain larry@wall.org:
>>
>>   http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-08/msg01111.html
>
> I don't see anything there that specifically says it can't be done, or
> that it shouldn't. Only that it's not easy...
>
>> Summary:
>>
>>   - "I'm not saying it's impossible, just that it's difficult."
>>   - "I also suspect that this could be generalized into a macro capability"
>
> So, aren't we all about making difficult things possible?

Just wanted to point out that perl uses heuristics to parse map BLOCK
LIST properly as it otherwise requires infinite lookahead to parse.
Perl gets it wrong regularly, although gets it right sufficiently more
than it gets it wrong that most people don't notice. Try for instance
sticking "use warnings;" (or no warnings;) as the first line of a map:

$ perl -wle'map { no warnings } @ARGV' 1
"no" not allowed in expression at -e line 1, at end of line
BEGIN not safe after errors--compilation aborted at -e line 1.

But put a semicolon right after the open brace and you trigger the
heuristic and it works:

$ perl -wle'map {; no warnings } @ARGV' 1

The proposal is to put in more infinite lookahead constructs, no doubt
requiring yet more heuristics (which will occasionally be wrong).

When these heuristics go wrong, and perl has more than people realize,
the general result is very strange error messages.

So to me the question is: is the feature worth the cost?

Anyway, I guess Ill wait for a patch, and see how it works out, maybe
the problem is easier than I think.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About