"Stephen P. Potter" <[EMAIL PROTECTED]> writes:
> * Socket functions (such as C<accept>, C<bind>, etc) should be moved from
> the core to modules/libraries.
> * Math functions (such as C<abs>, C<atan2>, C<cos>, etc) should be moved
> from the core to modules/libraries.
> * IPC functions (such as C<msgctl>, C<semctl>, C<shmctl>, etc) should be
> moved from the core to modules/libraries.
> * "User" functions (C<getpw*>, <endpw*>, C<setpw*>, C<getlogin>) should be
> moved from the core to modules/libraries.
> * Group functions (C<getgr*>, C<endgr*>, C<setgr*>) should be moved from
> the core to modules/libraries.
> * Network functions (C<getnet*>, C<gethost*>, C<getproto*>, etc) should be
> moved from the core to modules/libraries.
> * Process functions (C<getpgrp>, C<getppid>, C<getpriority>, C<setpgrp>,
> C<setpriority>) should be moved from the core to modules/libraries.
I don't think this has anything to do with the language. Whether a
function is built-in, known, loadable, findable, user-defined, or
whatever makes no difference from language perspective. See RFC26.
>From implementation perspective, yes, it makes sense.
-- Johan