Simon Cozens <[EMAIL PROTECTED]> writes: > Luke Palmer: >> So modules that introduce new concepts into the language can add new >> syntax for them without working with (ugh) a source filter. And some of >> these new syntaxes in the "core" language will actually be in standard >> modules, if they're not commonly used. Just like traits. > > This is good. This is what I like to hear. This is why the answer to > all these stupid syntax questions should be "Look, if you need it, > just put it in a module when we're done. But can we please get on > with getting Perl 6 designed and out the door, now?" > > But it isn't, and I don't know why it isn't, and so we end up > spending loads of time discussing things that can be punted out to > modules. Designing Perl 6 is hard enough; let's not try to fill > CP6AN at the same time.
But the vast majority of us *aren't* designing Perl 6, that's Larry and his team's job. We're in the position of taking the work that's been done on the language so far and working out how we'd use it (and yes, we're in the business of thinking about the sort of thing that will go in CP6AN). Considered in that light, Luke's question is a really good one, it points up an ugly idiom and considers how one would generate a better idiom in Perl 6. Where he falls down is in proposing new syntax to solve the problem rather than in proposing the new syntax and then offering a sketch of its implementation as a macro in Perl 6. After all, problems with 'implemented' solutions are simply demonstrations that the design is sound, and that's good feedback to Larry and his team. These things only become real design issues if there appears to be no good way to solve such problems.