Yes, you can do it with certain limitations and the loss of flexibility as a user function. The key question here is not whether "you can do it" -- but how convenient built-in will be in comparison with the "status quo", are key categories of users benefit directly from this addition (for Perl, first of all, whether sysadmins will benefit), and what is the cost -- how much trouble is to add it into the already huge interpreter, which inevitably increase already large number of built-in functions. As well as whether "in the long run" new functions can retire some "inferior" functions like chomp and chop (chomp is probably a bastard child of the absence of capability to suppress "\n" in the open statement)Implement head and tail functions as synonyms to substr ($line,0,$len) and substr($line,-$len)Nothing's stopping you from doing that right now.
NOTE: it is better to call them ltrim and rtrim, as it this case the second argument has a more natural meaning.
With chomp, which is far more frequently used out of two, replacing it by rtrim is just a renaming operation, with chop you need some "inline" function capability (macrosubstitution). So rtrim($line) should be equivalent of chomp($line) --assuming that "\n" is the default second argument for rtrim)
Also any user function by definition has more limited flexibility in comparison to the built-in function and is less efficient unless implemented in C.
Without introduction of additional argument for a user-defined function it is impossible to determine if the function ltrim has target or not -- called as subroutine (in the latter case it should modify the first parameter.)
So on user level you need to implement two: a function and a subroutine, for example: ltrim and myltrim)
Moreover, on user defined function level you have quite limited capabilities to determine the lexical type of the second argument (at run time in Perl you can only distinguish between the numeric type and the string -- not that regex is passed, or translation table is passed. Actually some languages allow to specify different entry points to the function depending on the number and type of arguments (string, integer, float, pointer, etc) passed. In Perl terms this looks something like extended prototypes:
sub name { entry ($$){ } entry (\$\$){ } }
A couple of examples:
The call ltrim($line,7) should be interpreted as
$line=substr($line,7)
but the call $header=ltrim($line,'<h1>'); obviously should be interpreted as
$header=substr($line,max(0,index($line,'<h1>'));
Also if you want to pass regex or translation table you need somehow to distinguish type of the last argument passed. So instead of the function call
$body=ltrim($line,/\s*/); on the user level you need to use
$body=ltrim($line,'\s*','r'); which should be interpreted as
if ($line=~/^\s*(.+)$/) { return $1; }
the same problem arise if you want to pass a set of characters to be eliminated like in tr/set1//d;
$body=ltrim($line," \t",'t'); # equivalent to ($body)=split(' ',$line,1);
One argument in favor of such functions is that in many languages the elimination of free space at the beginning and end of strings is recognized as an important special case and built-in function provided for this purpose. Perl is one of the few in which there is no such special operation and regex are typically used.
In reply to Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by likbez
in thread What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by likbez
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |