Racket is a language with a small community and a big space of things you can do. This means there's a lot of incredibly useful libraries and tools that nobody's had the time to make. This gist is a catalog of things I'd like to see made, maybe with the eventual goal of figuring out a way to coordinate with other community members in getting some of them done.
- More contract helpers like
predicate/c. Here are some possibilities:(list-repeating/c number? boolean? string?)- describes lists like(1 #t "foo")and(1 #t "foo" 2 #f "bar")(operation-> string?)- describes functions likestring-appendthat take any number ofstring?s and returns astring?. (no idea what to name)(rest-> string? number?)- All arguments arestring?s, result isnumber?. (no idea what to name)- More ideas in unstable/contract
- Better http libraries
- Header management is a mess. Headers are sometimes strings with a colon and space separated them, other times they're hashes of byte strings to byte strings, other times they're assoc lists of strings to strings.
- Current lib is completely embedded in the context of
web-server, so it's designed with that in mind. Extract out into separatehttplibrary. - Connection pooling is black magic to me personally, so I don't know about how well that's done. There's an http package by Greg Hendershott that does it.
- Typing. An http library should be typed. It's not doing anything generic, it's not doing very much that's higher order, it's mostly shuffling bytes and strings around and parsing them.
- Consider support for both sending and receiving requests and responses and make the interfaces identical both ways. REST APIs are getting increasingly common in this day and age, so Racket is seeing a lot more use on the client side of http connections. A Racket http library should be able to seamlessly do things like wait on a request, look at the given request, and fire it off with a different location but the same headers to a different url.
- Better metalanguage integration
- Meta languages that add readtable extensions should be able to easily and seamlessly integrate. Some do, but when you reorder them they break for non-apparent reasons. There should be tools for defining these kinds of languages that provide guarantees about iteroperability.
- Languages hooking in to things like #%module-begin and #%app should be parameterizeable to adjust the base one they're working on. This would let you use multiple languages that override application, like one that turns dictionaries into functions and one that turns underscores into magic functions, together. This would require standard libraries and tools for creating these kinds of syntaxes that ensure the proper hooking points exist.
- Library for doing things with points and cartesian space, pretty much exactly like what
pict3ddoes with 3d points, but as a separate standalone package that handles both 3d and 2d points.- Started at jackfirth/racket-posn, PRs and issues very welcome!
- Higher level web server tools designed exclusively for REST apis that have no mention of forms and templating and whatnot.
- Direct automatic support for content negotiation and JSON responses built in. This is pretty critical. The current trend of web apps is a rich client that makes AJAX calls to a data-only backend that knows nothing about html.
- Things like requesters with configurable add ons like following n redirects and retrying requests with backoffs
- More documentation helpers
#lang scribble/release-notes- Performance warnings,
@perf-warn{Frobnicating the widget without bizzbamming the froobnozzle severely impacts performance}becomes side note with standardized header of something like "PERFORMANCE WARNING" - Notes and warnings about unstable libraries, e.g.
@unstable-title{Foo}becoming Unstable Foo: May Change Without Warning @version{x}, notes version and provides info about specific version ranges, e.g. 0.0-1.0 is experimental- Mark specific functions as unstable
- Better in-source documentation
- Write docs in code in a
docproc-like way, in the same file the code is defined in. - Then include the docs with some sort of
include-srcdoc[foo proc-in-foo] - Do not include automatic contract-sharing in the manner of
scribble/srcdoc. This should be a better lower-level primitive library on top of which that can be added. - Look into extensions on top of this that allow using examples as unit tests.
- Write docs in code in a
- Tiny helpers in the main language
string->linesshould be built in
- A unified query language for use with
db- Steal as much as you can from LINQ, it's wonderful
- Possibly provide both a functional interface (functions accept queries and database instances and return new database instances or results) and an imperative interface (functions accept queries and database instances and return void or results)
- Seems this is part of the
racquelpackage, but it really needs to be it's own separate thing.
- Easier to add mouse over tooltips. Almost all tooltips just add information to an identifier. For that, something as simple as (define/tooltip id/header string body ...) would be ideal. Even when working with syntax objects in macro-land, this is still far more painful than it needs to be. I should be able to write (syntax-add-tooltip stx "foo").
- Deprecation library. Scribble @deprecated, tooltips shown in editor warning of a binding's deprecation, warnings printed at compile time when a deprecated binding is used, etc. Deprecation of functions, keyword argument names, argument positions, etc. Make this easy.
- REPL commands library. Given a bunch of procedures with descriptions, I'd like to bundle them into a module that provides a command-line / REPL interface to them. Turning positional args into command line args and keyword args into flags is a good example, for instance.