Front page | perl.perl5.porters |
Postings from August 2009
Re: A complete design for := (bind)
Thread Previous
|
Thread Next
From:
Chip Salzenberg
Date:
August 25, 2009 13:59
Subject:
Re: A complete design for := (bind)
Message ID:
20090825205852.GD12655@tytlal.topaz.cx
On Tue, Aug 25, 2009 at 10:21:58PM +0200, Abigail wrote:
> On Tue, Aug 25, 2009 at 12:48:41PM -0700, Chip Salzenberg wrote:
> > If we were to discard Perl 6 as a syntactic model and take only its useful
> > semantics, we could start with a proposal I made long ago but didn't work
> > all the kinks out of: lvalue refs. [...]
> > \$a = \$b;
> > (\@a, \@b) = (\@c, \@d);
> > \my($self, %args) = \(@_);
>
> The above are somewhat obvious. But it begs the question, what do the
> following mean? Would it even be legal?
>
> \$a = $b; # Runtime error if $b isn't a ref to a scalar?
> \$a = \@a;
Runtime errors, yes.
> \@a = [@b];
Legal: @a becomes alias for anonymous result of [], containing copy of @b.
> I don't think we need another smartmatch-like table to figure out what
> LHS ref vs RHS ref means.
Agreed, but fortunatately "RHS must match LHS" seems to work fine.
> I kind of like:
> my ($a, @b, %c)
> local ($a, @b, %c)
> our ($a, @b, %c)
> state ($a, @b, %c) # Yeah, if only it could do aggregates.
> bind ($a, @b, %c)
> I like a keyword because it acts a bit like my/local/our/state - but that's
> because I'm assume it will have some lexical scoped effect.
[BTW, the above parallelism is imperfect already: there's nothing that
makes C<local> inherently incompatible with the others. Dynamically
scoped save&restore of a lexical variable makes perfect sense. It's only
missing from current Perl because Larry thought it would be confusing; but
surely that horse has escaped the barn and *speciated* by now.]
I don't intend binding to be inherently scoped; like '=', its effect is
limited only by the nature of the target variable. Thus the original
proposal and Perl 6 use an operator ':=', which looks like '=' on purpose.
If not for the need to introduce the 'is' syntax or something equivalently
powerful, I would have preferred the LHS to be a simple LIST, which
simplifies simultaneous declaration. Is there any existing and flexible
syntax we can attach to arbitrary lvalues? I don't think so.
> But I find the feature to useful and important to spend too much time on
> bikeshedding the syntax.
I agree that the utility is much greater than max(annoyance) of a reasonable
syntax. It doesn't hurt to toss around some possibilities, but I hope to
settle on something worth implementing pretty soon.
--
Chip Salzenberg
Thread Previous
|
Thread Next