Package inclusion in R core implementation

As the original coder (in mid 1970s) of BFGS, CG and Nelder-Mead in
optim(), I've
been pushing for some time for their deprecation. They aren't "bad", but
we have
better tools, and they are in CRAN packages. Similarly, I believe other
optimization
tools in the core (optim::L-BFGS-B, nlm, nlminb) can and should be moved to
packages (there are already 2 versions at least of LBFGS that I and Matt
Fidler
are merging). And optim::SANN does not match any usual expectations of
users.

I'm sure there are other tools for other tasks that can and should move to
packages
to streamline the work of our core team. However, I can understand that
there is this
awkward issue of actually doing this. I know I'm willing to help with
preparing
"Transition Guide" documentation and scripts, and would be surprised if
there are
not others. R already has a policy of full support only for current
version, so
hanging on to antique tools (the three codes at the top are based on
papers all
of which now qualify for >50 years old) seems inconsistent with other
messages.

For information: I'm coordinating a project to build understanding of what
older algorithms are in R as the histoRicalg project. See
https://gitlab.com/nashjc/histoRicalg. We welcome participation.

Best, JN

On 2019-03-04 7:59 a.m., Jim Hester wrote:

Conversely, what is the process to remove a package from core R? It seems
to me some (many?) of the packages included are there more out of
historical accident rather than any technical need to be in the core
distribution. Having them as a core (or recommended) package makes them
harder update independently to R and makes testing, development and
contribution more cumbersome.

On Fri, Mar 1, 2019 at 4:35 AM Morgan Morgan <morgan.emailbox at gmail.com>
wrote:

Hi,

It sometimes happens that some packages get included to R like for

example

the parallel package.

I was wondering if there is a process to decide whether or not to

include a

package in the core implementation of R?

For example, why not include the Rcpp package, which became for a lot of
user the main tool to extend R?

What is our view on the (not so well known) dotCall64 package which is

an

interesting alternative for extending R?

Thank you
Best regards,
Morgan