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

Re: The future of POSIX in core

Thread Previous | Thread Next
Mark Overmeer
September 5, 2011 01:33
Re: The future of POSIX in core
Message ID:
* Father Chrysostomos ( [110905 05:31]:
> I don’t know where to find it now, but I seem to remember reading
> the proposed doc patch and noticing two things:
> 1) If it’s aimed solely at C programmers looking for Perl ways
>    to do things, it might be offputting for Perl programmers who might,
>    as a result, not learn about certain useful functions, such as floor,
>    ceil and fmod, which I use *all the time*.

Read "C programmers" as "programmers in any language which offers POSIX
compliant functions". That's a much larger group.

I always found it weird that "sin" is standard, but "floor" not.
Why do Perl programmers expect "floor" to be in POSIX in the first
place? Probably because "int" tells about itself that it is broken,
and refers to POSIX.

Math in Perl is a bit fague. Partially core, partially POSIX, Math::Trig,
Math::BigInt/::BigFloat, maybe PDL.  Fragments on how to do what are
scattered all over the place... For instance "perldoc -f sin" explains how
to create the "asin" with "atan2".  Where can I read about the rounding
errors which are caused by implicit conversions from string to float?

As far as I know, we do not have something like a perlmath manual
page. Having such a page would offer a spot to structually describe how
to use math better. The texts in perldoc for int, sin and more get far
simpler and easier to maintain by simply refering to that page.

Math is not limited to POSIX, so that is not the right manual-page to
explain or highlight it. And, simple math POSIX functions have loads of
consequences (often OS en specific hardware related) which are much
better explained in their operating system manual pages. We do not
need/want to repeat that. Therefore, I thing POSIX.pod can simply list
the math functions and point people to the OS for details.

> 2) The description for strtod discouraged its use, even though it’s
> sometimes indispensable.  If we are to discourage it, we should fix
> Perl’s number-parsing first.

Discouragement is not in the text I submitted nor in the current
manual-page. The only thing I did was to group strtod, strtol and strtoul
into one section so the long explanation how to use them did not have
to stay repeated three times.

The full text of the current state of my POSIX.pod replacement, (which
has not been adapted to the discussions of this week) is attached here.
Next week I hope to have time to create a bunch of patches for blead
which do follow peoples wishes. (You can contribute textual fixes now)

Do/can we fix Perl’s number-parsing?


       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