Ken Fox wrote: > If C<part> is not a method or multimethod, then it acts like a > reserved word or built-in, like C<grep> or C<map>. IMHO that's name > space pollution.
Yes, it is namespace pollution, but I don't think that's a problem in Perl. Many other languages have functions in the same namespace as variables; this is usually the biggest problem, since people tend to have more variables than functions. Perl's sigils means this isn't a problem: C<$part> or C<@part> cannot conflict with C<part>. Functions are all in a namespace. Perl providing C<CORE::part> doesn't preclude the existence of C<Ken_Fox::part> or whatever. Most core functions can be overridden, so even if you don't like the built-in behaviour you can change it, without Perl insisting on keeping the original name for itself. Perl 5 doesn't permit this with all built-in functions, but I'm hoping that the improved grammar and function declaration syntax in Perl 6 will allow many more built-in functions to be overridden. > How about formalizing global namespace pollution with something like > the Usenet news group formation process? Ship Perl 6 with a very > small number of global symbols and let it grow naturally. If the initial release of Perl 6 doesn't have commonly-required functions then people will write their own. People will do these in incompatible ways, ensuring that when it's determined that the language would benefit from having a particular function built in at least some people will have to change their code to keep it working. People will also choose different names for their functions. If C<part> only appears in Perl version 6.0.3, there'll already be dozens of scripts which have a sub of that name doing something completely different. Adding extra functions will create critical differences between versions of Perl with very small differences in their version number. People will get frustrated at needing a particular point-release of Perl to run programs[*0]. Or, alternatively, people will shy away from using those functions -- which by definition are so useful in every day programming that it's been decided to add them to the language -- because they want their code to be portable, thereby defeating the purpose of adding them. Perl 6.0.0 can't be perfect, but please can we aim to be as close as possible. Releasing a language with the caveat "but we've missed out lots of important functions that we expect to add in the next version or four" strikes me as a little odd. [*0] Yes, obviously this always applies to some extent: a point-release wouldn't be made unless it adds or changes _something_ in the language. But often these are small things, or tweaks to edge-case behaviour. Smylers
