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