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

Re: Time to update

Thread Previous | Thread Next
Mark Overmeer
January 31, 2011 05:00
Re: Time to update
Message ID:
* Tom Christiansen ( [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
> > 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.

       Mark Overmeer MSc                                MARKOV Solutions                         

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