develooper Front page | perl.perl5.porters | Postings from August 2009

Re: A complete design for := (bind)

Thread Previous | Thread Next
Ben Morrow
August 29, 2009 06:22
Re: A complete design for := (bind)
Message ID:
[Sorry for the late reply; I've been away.]

Quoth (Chip Salzenberg):
> On Tue, Aug 25, 2009 at 06:22:41PM -0400, David Golden wrote:
> > 
> > I get the sense that you're wanting to use the exact same syntax in
> > function signatures as in code.
> Well, sure.  If nothing else, it greatly simplifies instruction, and fails
> to induce bugs when pulling signatures down into the code.  For example,
> ignoring the 'my' issue, compare this wrapper-ish use case:
> # before:
>    sub foo (STUFF) { ... }
> # after:
>    sub foo {
>       return if $AVOID_FOO;
>       :(STUFF) := @_;
>       ...
> Keeping consistency in these cases is a goal I'm loathe to give up on.  But
> it isn't a hard-and-fast requirement.

I agree with this. Even having different ro vs rw semantics seems like a
bad idea to me, especially if we think explicit binds will be relatively

> >     sub foo(\$a, \@b) { ... } # aliasing
> >     sub foo($a, @b) {... } # copying
> You've forgotten, I think, that so far \@b vs. @b is our best Perl5-ish way
> to specify flatten or non-flatten.  Alias rw vs. alias ro vs. copy is a
> separate dimension.  The default case in Perl 6 is read-only aliasing, and I
> think that's a very good default: it is highly (if not perfectly) efficient,
> and also safe.  It would be bad Huffmanizing to require decoration to get it.

First: I don't like the ro-alias default at all. I would much prefer a
cow-alias: for one thing, it's not at all clear how 'deep' the
readonlyness should go. What if I pass an object and the function calls
some method that happens to change the internal state? Would this be a
runtime error? What about e.g. inside-out objects, where there is no
link perl can see from the object back to the state that needs to be
readonly? I realise that if Perl 6 is going to stick with ro-aliasing by
default it may be sensible for Perl 5 to do the same.

Second: how about using prefix-! for rw and prefix-= for copy? Prefix-!
is already invalid on the LHS of an assignment, just like prefix-\, and
the term/operator parsing rules should allow us to distinguish prefix-=
from binary-=. (This would mean that omitting a comma would have rather
bizarre consequences.) This would give something like

    sub foo (@a) {      # expects scalars, creates ro aliases
    sub foo (\@a) {     # expects array, creates ro alias
    sub foo (!@a) {     # expects scalars, creates rw aliases
    sub foo (!\@a) {    # expects array, creates rw alias
    sub foo (=@a) {     # expects scalars, creates copies
    sub foo (=\@a) {    # expects array, creates (1-level deep) copy

I'm not sure whether that should be '!\@b' or '\!@b', or either.
Explicit binding would be

    alias \@a, !\@b, =@c := @x, @y, $z;

or :() or whatever is decided, but in any case the same semantics as the
sub call.

Third: if we need some special syntax on the LHS of a bind (be it
punctuation or keyword), do we really need a special assignment operator
as well? We already have

    state $x = 4;

which isn't in any way an ordinary assignment, so what's wrong with

    alias $x = $y;

which has the advantage of being compatible with Data::Alias in simple


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About