develooper Front page | perl.perl5.porters | Postings from December 2008

Re: Proposal: Named parameters for 5.12

Thread Previous | Thread Next
From:
Tim Bunce
Date:
December 19, 2008 01:38
Subject:
Re: Proposal: Named parameters for 5.12
Message ID:
20081219093836.GA87380@timac.local
On Thu, Dec 18, 2008 at 10:04:55PM -0800, Chip Salzenberg wrote:
> On Fri, Dec 19, 2008 at 12:20:22AM -0500, Chris Prather wrote:
> > On Thu, Dec 18, 2008 at 11:57 PM, Chip Salzenberg <chip@pobox.com> wrote:
> > 
> > >> Either way, shouldn't we be aiming to match the syntax to the semantics
> > >> in a way that's consistent with Perl 6? In other words require "is copy":
> > >>      sub square ($num is copy) : method {
> > >
> > > Well ... that depends on the feasibility of read-only aliases, which I have
> > > yet to explore.
> > 
> > The ability to parse something as a no-op for future compatibility,
> > and the ability to make that do something need not be related.
> 
> True, that.  I think most people agree that parsing as much of the Perl 6
> syntax as possible is the base requirement.
> 
> But Tim had said 'require "is copy"', which goes farther.
> 
> If:
> 
>   (1) the only prototype that generates
>         my ($x) = @_
>       is
>         sub foo ($x is copy)
> 
> *And*
> 
>   (2) read-only aliases are not feasible
> 
> then this code
>   sub foo ($x) {...}
> must either:
>   (a) have a different meaning from Perl 6
>  or:
>   (b) not be allowed.
> 
> That's why I said it depends on the feasibility of read-only aliases

(b) is what I meant, and (b) doesn't depend on the feasibility of
read-only aliases.

But by disallowing now it we leave open the possibility of supporting
read-only aliases in future, if possible, with a compatible syntax.

Tim.

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