develooper Front page | perl.perl5.porters | Postings from September 2012

Features and keywords versus namespaces and functions

Thread Next
September 27, 2012 10:55
Features and keywords versus namespaces and functions
Message ID:
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

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?


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About