Front page | perl.perl5.porters |
Postings from September 2012
I would like to start a dialog about when it is appropriate to extend Perl via features and keywords and when it is appropriate to extend Perl via namespaces and functions. As far as I understand the feature/keyword approach is required when the change involves modifying how Perl code is parsed. For example adding a new infix operator has the potential of breaking code that uses the same token as a function name or worse cause it to be interpreted in entirely new ways without breaking. Namespaces on the other hand exist to work around the problem of function name collisions. They are the standard way to add library code to an application in Perl and virtually all other modern languages. I have seen and been involved in conversations where people have argued that new *functions* be added to the language as keywords and enabled as features instead of as functions in a built in namespace. I believe that this is a mistake and would like to begin a debate which I hope will lead to a new policy on this matter. The two main problems I have with adding new functions to perl as keywords/features are: 1) it balkanizes the language unnecessarily. We already have a lot of features and subtlety involved in perl, and the feature/keyword trend seems to make this worse. I now need to know what version of perl a piece of code is running under (something that is unlikely to be in the context of a patch) before I can understand it. I apparently need to know four or five separate dialects these days, with a new dialect seemingly being added every major release. 2) it does not easily allow new code to run on old perls - it is not as easily "shimable" in the sense that new functionality can be made available to older perls via modules which can be made to be no-ops on newer perls. One argument I am aware of in favour of keywords/features is that they are faster but this argument seems broken, if keywords are faster than built in functions then we should address that problem instead of working around it. So why do people want to use features instead of namespaces in this kind of way? Can we please adopy a policy that we do not add functions as keywords and instead use reserved namespaces for this? Note that all of the single word all lower case package names are currently reserved for core pragmatta, therefore we can legally repurpose them without breaking any compliant code. I will also note that we current *do* have a number of built in routines in specialized namespaces, and indeed some of those were not even put in reserved namespaces, so they could quite easily have broken code when they were added yet if they did it was seen as a minor issue. This is not a new precedent. I would really like to get this sorted out. I have a number of patches pending that I believe are useful and worthy additions to perl core which IMO are best added as functions in specialized namespaces and I would like to get the policy debate on this subject done independently of the merit debate that any such patch requires. IOW, I do not want to confuse a given contribution with this debate, I want this debate to be abstract. So to repeat for clarity: Under what circumstances should the Perl language be extended via new keywords and features and under what circumstances should it be extended via functions and namespaces? cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Next