> Are there any particular other operators you're worried about? > I think the current design does a pretty good job of factoring out the > metaoperators so that the actual set of underlying basic operators *is* > relatively small. Yes, you can now say something like > > $x = [»+^=«] @foo; > > but the basic operator there is just ^, with a + modifier to indicate > numeric XOR, = to indicate an assignment operator, »« to indicate > explicit paralellism, and now [] to indicate reduction, all in a nice > visual pill so you can think of it as a single operator when you want > to. But I didn't even think about adding a reduction metaoperator till > I wanted it for something else in the design that had been bugging me > for a long, long time. Almost nothing in the design of Perl 6 is there > for a single purpose.
"The basic operator is ^." ..... I've been programming for a while, following P6 pretty heavily, and I would not have been able to parse that out of the 6 characters. My basic concern is that [»+^=«] looks like line-noise. Yes, I can parse it out, given time and understanding of the various operators, but that's starting to smack of golf in production code, even though it's not. > : What happened to the idea of having modules that define syntax? Did I > : miss a change in focus over the past few months? > > Nope. You can still warp syntax as much as you like. But we'd like > to discourage people from doing that by default merely because the > core neglects to provide a standard default solution. > > That was the big problem with Perl 5's OO design. It was too minimal. > It didn't specify an obvious way to do it, so everybody rolled their own > in an incompatable fashion. No-one came up with an incompatible way to do CGI or to handle filenames, yet neither is within the language. If p5p had provided a Class::* module within the core, that would have been the standard. Now, this wouldn't have prevented others from providing alternatives (such as CGI::Simple for CGI), but there would have been something people could reach for if they needed it that would be installed. (I actually think this was a mistake p5p made.) Operators like [] and >><< can be provided for in a standard way, yet not be in the core language. I'm not arguing against the operator itself - I like [] as a reduce() circumfix operator modifier and wish I had a way of putting it into Perl5. But, I would love to see it as: use operator::reduce; use keyword::flarg; That way, you have the ability to document the usage of some of the "weirder" operators. Here's the base concern - I program Perl for a living as a contractor. Every site I go to, I'm told "Don't use those -weird- features". The features they're referring to? map/grep, closures, CODErefs, symbol table manipulation ... the standard basics. If the feature was in a module, kinda like a source filter (but not as sucky), then the feature is more palatable because everyone has a chance to agree that it should be added. It's stupid, but it's easier to get everyone to agree to add the use of a module than to use a builtin feature. I don't understand why, but that's my experience across 4 states. *shrugs* *thinks for a minute* [»+^=«] reminds me of a P5 regex that has a comment saying "This is black magic. Don't touch!". --That's-- my complaint. Rob
