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:
Brad Gilbert
Date:
July 11, 2012 09:32
Subject:
Re: What would having a & prototype after the first position break?
Message ID:
CAD2L-T1skXssrrZt26OFDiDysLymASXTrszn21yJHfgv7UtLQg@mail.gmail.com
On Wed, Jul 11, 2012 at 1:35 AM, demerphq <demerphq@gmail.com> wrote:
> 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/"

As long as these statements apply to your code, I don't see much of a problem.

- doesn't break code that doesn't use it ( that isn't already broken )
- doesn't significantly slow down perl during compilation
- doesn't slow down perl during run-time
- doesn't crash perl
- is heavily tested

---

Off-topic:

It would be nice if there were a way to specify this in a prototype,
and have it actually work:

    sub foo([&\%]){...}

because this

    sub foo(\[&%]){...}

only accepts code-references of the form:

    foo &bar;

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