move special functions out of Base?

[nolta]

Continuing the discussion in #8294, now that the amos code has been converted to julia, do we want to start moving the special functions (e.g., airy*, bessel*, hankel*) out of Base and into a package?

[JeffBezanson]

This issue can fight it out with #4301 :)

[ViralBShah]

Cc: @lindahua

[tkelman]

This didn't get much attention, but I'm in favor of it primarily because it gets rid of a Fortran dependency with a pretty minor performance cost. Does anyone use these special functions frequently enough that moving them into a package would be a major hassle for them? If so then no rush, we can wait until package precompilation is working well I suppose.

In order for this to happen, SpecialFunctions.jl would have to be fleshed out the rest of the way by copying over the docs (tests look like they're copied already?) from the relevant parts of base / openspecfun, registered and tested (on travis and package evaluator).

[simonbyrne]

I'd be okay with this as well.

[nolta]

I guess we need to resolve the "big Base vs small Base" argument first, e.g., #75.

[tkelman]

And #5155, #1906 and a few others. I feel like the more-or-less consensus for the right thing to do is small[er than now] base with a good mechanism for making bundled installs including most of the commonly-used packages by default, preferably precompiled for fast load times.

We haven't implemented either bundled-with-packages installs or precompiled packages yet. But at least for something small and maybe not-so-widely-used like this it could be good to do a dry run of what the process of migrating things out of base looks like, regardless of whether the nice-to-have features are ready yet. We've seen several cases of packages moving into base, especially when replacing troublesome binary dependencies. Not so many cases of the other way around recently, since the original creation of the package manager right?