JacquesCarette
Re-splitting drasil-utils
(A lot of the analysis behind this issue is in #2883; specifically in the 'shallow analysis' for drasil-utils).
The conceptual integrity of drasil-utils is low: its only concept is to collect together "utility" routines for other packages to use. That it does, but it collects a hodge podge of things that are unrelated to reach other.
So drasil-utils is more akin to a small set of utility packages. Some of them are on top of Haskell's base, others are really on top of (parts of) drasil-lang. Operationally what's needed is that some of #2885 needs to be done first, so that new small packages are exposed that the pieces here can depend on. Then an active decision will need to be made to either push the utilities into the new packages, or to create a separate drasil-X-utils package (as we still don't want too much bloat). Exactly what to do is dependent on the details of what happens in #2885.
Unfortunately, I'm struggling with finding a suitable entry point for #2885 to "get the ball rolling." Would it be alright if I started instead by forcibly pushing the drasil-lang-related "utils" out of drasil-utils and back into drasil-lang? This would allow me to invert the dependency of drasil-utils on drasil-lang and push many "utility"-like functions out of drasil-lang and into drasil-utils. This would simplify moving the "documents, people, references & citations" outside of drasil-lang.
