This may be a naive question, but what's wrong with just having a keyword called reduce()? Why do we need an operator for everything? I'm worried that the list of P6 operators is going to be as long as the list of P5 keywords, with a lot of them looking something like:
<verb><direct object><indirect object> I propose that if you're thinking of using 3+ ASCII characters for an operator that it should just become a keyword. For one thing, it's more maintainable that way. I can remap ^K in vi to be 'perldoc -f" instead of 'man' and it will work for keywords, but not for Unicode operators. Rob On 5/4/05, Larry Wall <[EMAIL PROTECTED]> wrote: > I propose that reduce become a metaoperator that can be applied to > any binary operator and turns it syntactically into a list operator. > I am currently thinking that the metaoperator is a prefix spelled \\ > (though there are certainly lots of other possibilities that I've laid > awake all night thinking about). There are the usual suspects like: > > $sum = \\+ @array; > $fact = \\* 1..$num; > > Then there are some rather interesting ones like: > > $firsttrue = \\|| @args; > $firstdef = \\// @args; > @sumrows := \\+« @rows; > > I particularly want this to replace the semantically ugly "dim" operator > (used to be "semi") in multidimensional subscripts: > > @foo[0..9; \\;(@dims); 0..9] > > Also, by the way, infix:<;> now only creates arrays of lists only in > contexts bound to something like > > Array [EMAIL PROTECTED] > Lazy [EMAIL PROTECTED] > Eager [EMAIL PROTECTED] > > This is how the parameters to a subscript are declared, so they > automatically get a list of lists, even if there are no semicolons > in the subscript. This gets rid of the "retroactive semicolon" > problem once and for all. > > In ordinary list context, infix:<;> is just a list-op-ending "big comma", > but is otherwise treated like an ordinary comma (but only if the > list is in some kind of brackets, of course). > > Now here's the interesting part. The same critera apply to extra > lists added with <== or ==>. In other words, a function may be be > declared to recognize multiple input pipes as separate lists just > like a subscript recognizes multiple dimensions of slices. But the > default is to flatten all input pipes into a single input stream. > > The new semicolon semantics are relatively non-negotiable, but feel > free to hash out the reduce metaoperator. Perhaps \\ is the ASCII > version, and people will prefer to write something with less visual > confusion and more mnemonic power: > > $sum = (r)+ @array; > $fact = (r)* 1..$num; > $firsttrue = (r)|| @args; > $firstdef = (r)// @args; > @sumrows := (r)+« @rows; > @foo[0..9; (r);(@dims); 0..9] > > Hmm, that kind of says that the ASCII workaround should be: > > $sum = (R)+ @array; > $fact = (R)* 1..$num; > $firsttrue = (R)|| @args; > $firstdef = (R)// @args; > @sumrows := (R)+« @rows; > @foo[0..9; (R);(@dims); 0..9] > > Which does have the benefit of not letting people confuse \\ with // > semantically or visually. I guess (R) would be a Texas reduce. :-) > > Larry >
