First, thank you for all the great pointers in this thread. It is clear that different renderings will be useful in different contexts, and there's good libraries to leverage in the community. That's what I was hoping.
(I'll add Github as a second push destination shortly.)
There's a story about how I'm at the point of writing this library. The short version is that I would like to be able to do simple exploratory data analysis with relatively small data in simple ways. The word "simple" is grossly loaded in this context, so I'll just say that I want a library that supports introductory exploratory data analysis in an HtDP context, and I want it to have a pedagogic growth path, so that if students go off to use Python/NumPy/SciPy, or R/Tidyverse (or, horrors, plain R), then they've had the conceptual base to know what they want to do, even if the syntax, semantics, and learning materials are against them.
This was a first dive into starting to think seriously about syntax-case and syntax-parse, and that probably led me down roads that were not entirely productive. I did a lot of implementation work as I explored.
In the last few days, I threw out 3000 lines of exploration, and rewrote it in 300, much more of which is tests. In particular, I decided that everything I wanted to do could be handled by an in-memory SQLite database, I could leverage Ryan's excellent 'sql' library, and in doing, effectively design a small "language" (API? interface? perhaps someday a #lang?) that wraps operations on that data. However, the design of that is subject to discussion and debate, and it might be that the library ultimately encapsulates more than one interface, so that different kinds of data questions can be asked differently.
So, the abstractive lift of using db/sql was huge, and I also like rackunit/chk. I'm also wrapping some parts of plot, so that I can have really, really short pathways to investigating data. It's early days on the pieces (which, in the rewrite, I sprinted based depth to instead stitch a complete pipeline in the name of proof-of-concepting the choice to backend to SQLite). Wrapping everything under a single require, etc., hasn't happened yet, testing is reasonably underway, and documentation on the rewrite is currently lagging.
;; read-gsheet takes a version published/shared as a CSV
(show (scatter T "LonD" "LatD"))
These two lines let me read in a CSV published via Google Sheets, and get a scatterplot in DrRacket.
So, that's a long story. However, I'd welcome dialogue. I may come back with some specific questions. For the moment, I'm exploring. I had (and will have again) the ability to slurp in SQL databases (SQLite, MySQL, etc.), I currently do CSV files, and would like to output a number of these formats as well. In terms of plotting, I'd like to support basics (think early chapters of Tukey) with some customization, but ultimately know that I can always drop down to full 'plot' if I need to.
The output of the table question is so that students can have a richer view into the tables they're working with. A lot of good pointers were in this thread.
That's long, but there you go. That's the story. A short version may be "I'm standing on the shoulders of giants," because the rewrite feels like a wrapper around sql and db... which, frankly, is lovely. (And, I'm almost starting to understand how to use the various quasiquoting syntactic forms in the sql language to build my own frankensteined queries...)