> > What I was suggesting was to consider broadening what the
> > $foo : bar style postfix sub syntax allows/assists bar to do,
> > so that bars can be used to set properties OR do other stuff.
> >
> What's the practical utility of this?


1. Simplification for perl 6 implementation. I would expect it to be
easier, when implementing the case of a user-defined property
setting sub, to implement this as a straight reuse of existing perl
functionality, namely use of plain old subs and $_ aliasing, than
to invent some alternate mechanism purely because it is deemed
evil to even have the option of changing the bar'd value.


2. Simplification for explanation. A value property setting sub is
just a sub that happens to set a value property. Oh, and by the
way, the most convenient and expressive notation for calling
value property setting subs is the one we taught you for applying
a sub to a value, namely one gets to:

    return $foo : bar;

from

    @foo := bar;    # already gonna have to be learnt for perl 6


3. Availability of another, brief, convenient and expressive way
of calling subs with one argument on the left:

    OUTPUT : open ">foo";
    OUTPUT : print "bar";
    OUTPUT : close;
    
I realize that a more general mechanism for postfix (or more
accurately, infix) subs is hoped for, and, depending on how
that looks, it might well make the above example pointless. Or,
the more general mechanism for postfix/infix might subsume
the above, so that property setting is just a way to use a sub
with one of its args on its left, and that is just one of various
postfix/infix options available.



> > Once one takes that step, : can become a generalized "apply
> > to value(s)" character, and the next natural step is:
> >
> >     @foo := bar;    # iterate over @foo, applying bar to values.
> >
> Actually, Larry has already indicated in an earlier message to
> the list that ':' will work a lot like that!

Yes, that was part of my reason for posting this. I thought it was
interesting how the syntax fell in to place nicely for what Larry
had already said he wanted, if ':' property setters are allowed
to generalize to being subs (or blocks or -- I have more ideas
on this, but they can wait or die with this thread) that can see
and change the values from their left hand side.

A key point here is that value properties apply to values, not
variables, and element-wise operations also apply to values,
not variables. Given that they share this applicability aspect,
and (coincidentally?) shared ':' in proposed syntaces to date,
I thought there might be value in looking at just how they might
fit together.

Reply via email to