I should point out that one of the major changes in the most recent
S6 is that named arguments are now marked by : rather than +, with
:foo($bar) being the way to declare parameter $bar but give it the
external name of "foo". A + is now reserved to mark mandatory
parameters, though it's redundant on positionals. A mandatory
named parameter is now marked +:$nonoptionaloption.
But the colon sigil might be more general than that. In rvalue context
the prefix it could be a modifier on the following term, causing
it to return a pair or pairs when it would return a scalar item.
The generated name is derived from the immediately surrounding
container, where that might be the variable name, the hash key,
or the array index. An unsubscripted container counts as a scalar.
So we'd get:
Term Short for
:$foo :foo($foo)
:@baz :baz(@baz) (not @bar.pairs)
:%bar :bar(%bar) (not @baz.pairs)
:%hash<a> :a(%hash<a>)
:%hash{$k} $k => %hash{$k}
:@array[42] 42 => @array[1]
Again, as with :foo, we're banking on the initial double-dot as
a mnemonic indicating that the following thing should be in "pair"
context. I wouldn't bother proposing this except that it maps nicely
onto the parameter syntax for named args, and it also eliminates some
amount of redundancy.
The last three forms are more arguable than the first three, especially
since they probably aren't valid formal parameters. We kind of need
a subscript modifier instead:
%hash:<a> :a(%hash<a>)
%hash:{$k} $k => %hash{$k}
@array:[42] 42 => @array[1]
@array:[] @array.pairs
%hash:{} %hash.pairs
Unfortunately that would force
$obj.sort:{...}
to be written
$obj.sort :{...}
But then, I'd surely love to get rid of that colon on magical
blocks. It's the main place where Ruby is still prettier than Perl 6,
bikesheddily speaking. Even
$obj.sort: {...}
would be a vast improvement, though that has ambiguities with indirect
object syntax. Maybe we can still finesse it somehow. It's really
only ambiguous if there's a bare identifier in front somewhere:
foo $obj.sort: {...}
While we could decide based on the presence of such an unresolved
work, I think that allowing methods as list ops is actually more
important than indirect object syntax, so I think we can say that
".foo:" is always a list operator form of ".foo", and you have to say
foo ($obj.sort): {...}
to get the other thing. But in either case the trailing colon
postfix indicates a following list. And I think people will
naturally want the colon to bind more tightly to the immediately
foregoing thing anyway. Like placeholder syntax, indirect object
syntax is really only for simple cases.
Er, looks like I have to revise S6 yet again...
Larry
