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:
Chris Nehren
Date:
July 4, 2012 10:27
Subject:
Re: What would having a & prototype after the first position break?
Message ID:
20120704172726.GC6569@isuckatdomains.isuckatdomains.net
On Wed, Jul 04, 2012 at 17:54:40 +0200 , demerphq wrote:
> On 4 July 2012 06:58, Chris Nehren <c.nehren/p5p@shadowcat.co.uk> 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;
> >
> > 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?
> 
> How is the interpreter to know that those arent hashes?
> 
> Yves

Because I asked it to with a (&&) or ($&) prototype.

To be clear, I am proposing a change to perl to enable that &
prototype after the initial position--this is expressly *not* supposed
to work with present perl. It is more consistent, at least to me, that
the first position of a prototype not be special with regard to the &
prototype specifier.

Given this:

sub foo(&) { ... }

foo { ... };

How does the interpreter know that the {} construct after foo isn't a
hash? The prototype says so. In present perl, this is valid:

use strict;
use warnings;
sub foo(&) { my ($code) = @_; $code->(); }
foo { qw/foo bar baz quux/ };

It doesn't really do anything, but it doesn't explode, either.[0] We're
obviously passing what should be interpreted as a hashref to foo. Maybe
you meant, "How can we add error-checking to this handle the case that
the {} thing passed in is actually a hash ref and not a code ref?" In
that case, we already have syntax for disambiguating between code and
hash refs. And in present perl we don't explode if the thing passed to a
sub(&) is a hashref, as demonstrated above. Why should it be any
different if we change perl to accept a & prototype after the first
position?

[0]: IMO it should (or should at least warn), but that's a discussion
for another thread.

-- 
Chris Nehren           | Coder, Sysadmin, Masochist
Shadowcat Systems Ltd. | http://shadowcat.co.uk/

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