A list of Racket package tags to be used in The Great Catalog Tag War

package-tags.md

• app provides an application for users, rather than a library

• app-syntax provides a general-purpose #%app syntactic form, such as dictionary lookup through #%app

• concurrency provides something useful for concurrent programming

• config something related to configuration, such as reading from env vars or flags

• crypto something related to cryptography, including hash algorithms and TLS bindings

• data provides a data structure of some sort

• datetime something related to dates or times

• debug something related to debugging programs

• deprecated something considered old and no longer supported

• docs provides documentation of something, useful for "-docs" complement packages

• documenting provides something useful for documenting code

• editors something related to IDEs and code editors, such as DrRacket plugins

• experimental not yet ready for use by those who don't want to worry about their dependencies breaking their APIs

• ffi provides something useful for Foreign Function Interfaces (for calling code in binaries outside the Racket binary)

• functional provides something related to functional programming, typically a combinator library or some other Haskell-ish concept

• game provides a game or other interactive entertainment app

• gamedev provides something useful for game development, such as a game state engine or 3d graphics

• graphics provides something related to drawing, images, or GUIs

• io provides something related to reading and writing data

• lang provides a #lang language

• learning provides resources for learning, such as a tutorial, book, or example use of something

• logic something related to logic programming, such as a constraint solver

• match something related to pattern matching (typically extensions to the built in pattern matching library)

• network provides something useful for making network calls and implementing various protocols

• parsing provides something related to parsing unstructured data into structured data

• performance something related to performance, including benchmarking or ultra-fast-but-unsafe data structures

• personal provides something meant for a specific person, such as a grab bag of personal utilities

• raco provides a raco command

• reader provides something that modifies the racket reader, such as adding reader syntax for shorter anonymous functions

• reflection provides something related to dynamically reflecting on typically static program information, such as a library for programatically inspecting scribble docs or dynamically proxying values

• repl something related to REPLs

• service something related to calling out to an external service, such as a Github client API

• storage provides something useful for persistent storage of values, such as database clients

• sugar provides a simple shortcut that's generally useful and not specific to a particular library

• syntax provides something useful for macros and other syntax object manipulations

• terminal provides something useful for interacting with the terminal, such as a toolkit for making a terminal GUI or a library for building command line tool interfaces

• testing provides something useful for testing code

• tests provides tests of something, similar to docs tag

• text provides something related to strings and/or text

• types something related to types or type systems

• utility a small utility package of some sort, often a bundle of miscellaneous functionality

• validation something related to validating data or matching data to a schema

• web something related to "Web" technology, such as html/xml parsing, CSS engines, racket-to-javascript compilers, REST frameworks, etc.

Packages that provide something directly related to another package should have the name of the other package in their tags. Some packages split up their implementation, tests, and docs into separate packages, e.g. a foo package would be a super-package that implies the foo-lib package, the foo-test package, and the foo-doc package. Each of the foo-lib, foo-test, and foo-doc packages should have a foo tag to link them to the foo package. (NOTE: not sure whether the foo package itself should have the foo tag, that seems redundant and like something the UI should be smart about)

I understand why you chose documenting. Are most of them also scribbling? The nice thing about the second name is that we use scribblings as a directory in the tree a lot

documenting would be for things like the abnf package (which provides utilities for BNF grammar in scribble docs). I wanted to avoid prescribing a particular documentation technology, but unlike the "testing" tag there's really only one documentation "framework" used by Racket code. Plenty of non-rackunit tests exist. I still like documenting over scribbling because it has the nice symmetry where documenting is related to docs in the same way testing is related to tests.

What about the -lib packages? Should they have a "libs" or "lib" or "implementation" tag?

Also, quite a few people have packaged their own utility toolkit (adjutor, lathe, phc-toolkit, axe, mischief, bazaar and probably a few others). Usually, this package is experimental/unstable. We'll probably need an "util" or "utility" or "toolkit" tag for these.

@jsmaniac I'm not sure what to tag -lib packages, or if a tag would be beneficial. The package UI could probably do something smart with 'implies instead, like grouping implied packages together. As for utility packages, I think a "utility" tag combined with the "personal" and "experimental" tags would work. The "personal" one can be dropped if it's intended to be used by others too.