Julia: move Base functions that are meant for interactive use

[JeffBezanson]

I think we should follow a principle that functions meant for interactive use should not be exported from Base. From a quick pass through, I think these are all the functions I'm talking about:

edit
less
code_warntype
code_llvm
code_native
methodswith
varinfo
versioninfo
which
subtypes
dump
@which
@edit
@less
@code_warntype
@code_llvm
@code_native

The idea is that a function like methodswith is informational only, and if your program or library depends on it you're probably doing something wrong. We want to make it clear that these are REPL-only. I propose moving them to an InteractiveUtils stdlib package, and putting using InteractiveUtils in the default .juliarc.

[KristofferC]

Having to using something for a quick code_warntype seems annoying but then one could just put it in .juliarc.jl, I guess. Do that by default?

[JeffBezanson]

Yes I proposed that in the OP :) I think the special case is justifiable since the whole purpose of these functions is interaction.

[JeffBezanson]

Or, the REPL could inject it into your session.

[ararslan]

The REPL stdlib package could reexport InteractiveUtils.

[KristofferC]

But you are not using REPL to use it though.

[StefanKarpinski]

The REPL could implicitly do that when it starts.

[ararslan]

I didn't realize that it doesn't already do that. That seems like fairly sane behavior, depending on what REPL exports.

[JeffBezanson]

I think this should be a separate package, since you don't need it to implement a REPL, but the REPL can inject a using InteractiveUtils into your environment. That way we don't even need to touch .juliarc.jl.

[yurivish]

Calling the module InteractiveUtils seems to presume a certain set of use cases, and I can imagine others that aren't interactive (such as an automated tool for building a summary report for a package; such a script may want to use e.g. subtypes and methodswith and would not be confined to interactive use). Maybe it can be called something like ReflectionUtils instead?

[JeffBezanson]

Maybe subtypes is a slightly different case. I'm mostly after stuff like edit. But I also think that use case is one where you should think twice about using subtypes; there's a very good chance it doesn't do what you want. Putting it the InteractiveUtils package signals that --- this is a fuzzy function for people, not something well-defined in the language.

[yurivish]

Oh, weird, I thought that it did exactly what it said: subtypes(T::DataType): Return a list of immediate subtypes of DataType T.

So you couldn't use it to draw something like a type tree of the abstract and concrete types defined in a package? I know there are multitudes of other subtypes (e.g. Unions), but I figured that it was well-defined.

Things like edit and less are definitely for interactive use, so that makes sense.

[JeffBezanson]

I guess you could use it for that; you would get some kind of a reasonable tree. But if you wanted to do that, I think it'd be fine to have to write using InteractiveUtils :-)

[yurivish]

If you say so. It'd feel odd to me. :-)

I always pictured subtypes and which as in the same family of reflection functions as things like fieldnames.

Functions like code_llvm are more clearly meant for direct human consumption as they are defined to print their results, but I'd imagine that eventually there would be machine-friendly analogues of those, too.

[JeffBezanson]

Yes, which is pretty reasonable. It's well-defined, but the result changes depending on what code is loaded. subtypes is similar, but slightly sketchier since enumerating subtypes is something the language never does, while we clearly look for matching methods all the time. I've been meaning to move subtypes out of reflection.jl for some time now.

fieldnames is a much lower-level (pure) function.

[antoine-levitt]

That looks potentially extremely confusing : if I use those functions in the REPL, put them in a script, run that script at the REPL, then run that script non interactively and get an error, how am I supposed to find out what's going on?

[StefanKarpinski]

Documentation? It's hard to imagine why you'd want most of these in a script...

[antoine-levitt]

There's no particular reason I'd go looking at the specific place where this is discussed in the docs if I don't know already I should look there. About use, I often use @code_warntype f(a,b,c) in the middle of a function (followed by a "STOP" to stop execution) to avoid figuring out the types of a b and c and calling f from the REPL.

[vtjnash]

I think we could print something to tell you about the REPL environment customizations:

   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: https://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.7.0-DEV.3583 (2018-01-26 01:28 UTC)
 _/ |\__'_|_|_|\__'_|  |  master/067e49164d* (fork: 3 commits, 0 days)
|__/                   |  x86_64-apple-darwin16.7.0

[Main] using Standard Library
[Main] using OhMyREPL
[Main] using Statistical Analysis
julia> 

Where these are meta package-names. "Standard Library" would be defined as bringing in LinearAlgebra, Random, InteractiveTools, CodeReflection, Regex, Profile, Docs, and maybe some others (like the package manager, Revise.jl, and debugging tools) and would be the default. The .juliarc.jl file can configure the REPL options to pull in different packages as the defaults, based on what the user needs most frequently. For instance, OhMyREPL could get mentioned. Someone might want to have or define a standard "Statistical Analysis" configuration (DataFrames, Distributions, JLD/CSV/JSON, RMath). Or a "World Wide Web" configuration (HTTP, SQL/SQLite/ODBC, JSON, React/Escher)

[StefanKarpinski]

That's a good idea. It could be based on environments in your LOAD_PATH potentially, i.e. have some sort of configuration in each Project.toml file that indicates which packages to auto-load in the REPL.

[stevengj]

I think we could print something to tell you about the REPL environment customizations:

That doesn't seem like something you'd want to do in an environment like Jupyter, Juno, etcetera, where you would also want to export these functions.