Larry Wall wrote:
On Wed, Sep 20, 2006 at 05:18:12PM -0400, Aaron Sherman wrote:
: For this reason, I'd suggest putting away the Latin-1 glyphset and
: instead focusing on developing operators to act on containers with
: multiple access methods and their expanded forms.
There's already going to be such an operator, and it probably won't be
Latin-1. The only question in my mind is whether it's also a sigil.
Well, that sounds reasonable enough. Let me take the last point, then,
which I'm only slightly convinced I have a good answer for: They just
don't seem important enough to pump out another sigil for. Filehandles
are FAR more valuable and potentially semantically rich, so I would
expect them to get their own sigil long before captures. If captures
have an expand-o-op, then I think they have everything they need to be
on-par with features like filehandles.
: When we want to turn a capture that is stored in a scalar into a
: signature, we need an operator that performs that action, and
: unambiguously does NOT perform the action of turning it into a list. I
: suggested some in my previous message (such as <-- and $\).
The Style Police have rated those as slightly less ugly than [,]=.
My problem with [,]= is not that it's ugly (it is, a bit), but that it's
two operations which are both being slightly bent out of shape for their
use here. I do agree that capture expansion is something which demands
its own op.
: Subroutines just so happen to take signatures, so you can invoke them
: with one:
:
: foo(<-- $capture);
: foo($\ $capture);
That's foo(|$capture) now.
Hrm... ugly is one thing, but visual ambiguity is another. With an
operator like <-- one can use or discard the parens at will. However,
with | there is no alternative, since:
x |$y
could be a programmer trying to say:
x() | $y
I cry for a Q/A group every time I see that kind of thing go into Perl
6. It's especially unfortunate because there might be a fair amount of
value to coercing simple types into captures, but we don't want to in
this case, so that we can catch such errors.
...
In my current thinking that's just \( |$othercap, $a, :$b ).
Yep, if |$ is the capture sigil (making | the sigil prefix op) then this
is a fairly obvious extrapolation from your previous messages.
: Calling subroutines with such a thing looks nice and clean:
:
: $values = \([EMAIL PROTECTED], [EMAIL PROTECTED], $c, :mean<1>);
: $avg1 = avg(<-- $values, :undef<ignore>);
: $avg2 = avg(<-- $values, :undef<iszero>);
:
: That's as simple as you can get, and we didn't have to promote captures
: to a new kind of sigil type to do it.
I think | is a lot nice-and-cleaner and simpler than <--. And it
can also work as a sigil.
Keep in mind that, while <-- is my strongest current idea, I'm more
advocating the "non-ambiguous, non-sigil" idea, and not championing any
particular implementation of that idea.
One reason that I liked <-- was for the fact that it looks like -->
which defines return type inside of a signature. Though it's not clear
to me if knowlege of expected return type is wrapped up in a capture. If
so, then perhaps this is how you re-dispatch with a forced/overridden
context:
callargs(<-- $args -->Int);
Though I admit that's going to catch HTML/XML programmers off-guard ;)
