develooper Front page | perl.perl5.porters | Postings from January 2011

Re: Time to update POSIX.pm?

Thread Previous | Thread Next
From:
Mark Overmeer
Date:
January 31, 2011 05:00
Subject:
Re: Time to update POSIX.pm?
Message ID:
20110131130044.GI13263@moon.overmeer.net
* Tom Christiansen (tchrist@perl.com) [110131 12:25]:
> Mark Overmeer wrote:
> > For about 50 functions offered by POSIX, the name is 
> > directly calling a CORE function with the same name.
> 
> I was looking at that myself.
> 
> > Wouldn't it be cheaper to alias the names?
> Cheaper at which level?  Is this merely to skip one 
> call frame?  Is this the right kind of optimization?

We have more of these optimizations in modules.

>> In a dozen cases, the function maps to some perl internal:
>>  sub tolower { lc($_[0]) }
>>  sub getpid  { $$ }
      [...]
>   * The CORE functions do not really live in some mythical
>     %CORE:: symbol table.  They are a product of the lexer
>     alone.  That means there's no function to assign to the
>     the right slot in the glob.  For example, these are 
>     both equally useless:
> 
> 	*POSIX::tolower =  *CORE::lc;
> 	*POSIX::tolower = \&CORE::lc;

The cited paragraph was not about aliasing anymore.  But anyway, I did
not know this. So, aliasing is not possible as optimization

> Only in a few cases.  For example, what do you really think
> strlen() ought to do?  By POSIX definition, it gives the length
> of the null-terminated string in bytes.  That's a C-specific 
> definition that makes next to no sense in Perl.

With the same flexibility as the current error "use length()", you
can implement it to use length.

> > A non-breaking change for consistency would be to implement
> > these functions as [well] as we can. They then change from run-
> > time errors into well accepted.
> 
> Into well-accepted what?

Sorry.  "into accepted calls."

> > A seriously breaking alternative would be to degrade POSIX.pm
> > into a module which only exports constants and functions which
> > are not provided by the standard Perl interface (like
> > ctermid()).
> 
> Why might one care to do that? 

IMO, you should either implement something perfectly or not. Certainly
for a Perl code module. The Perl functions are much smarter than the
POSIX functions, and often behave just a little differently. Not
perfectly than don't provide it. Probably deprecate the use first?

> I do have one other matter to raise, with some trepidation:
> If we're really mapping POSIX::lc() to CORE::lc(), isn't 
> that going to go through the full Unicode case-mapping, and
> isn't that different from POSIX case-mapping? :(  [*DUCKS*]

Just what I mean with "one-on-one mapping from POSIX to Perl" isn't
correct. The current implementation is too limited, if feasible at
all. Of course, it fitted better with "classic" Perl versions.
-- 
Regards,
               MarkOv

------------------------------------------------------------------------
       Mark Overmeer MSc                                MARKOV Solutions
       Mark@Overmeer.net                          solutions@overmeer.net
http://Mark.Overmeer.net                   http://solutions.overmeer.net

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About