The internal Urbit standard library, as contained in hoon.hoon and zuse.hoon, has largely been architected for building Hoon itself. This means that one of the highest-leverage software development efforts we can make is to produce a middleware userspace standard library that does everything a “normie” dev would want, with names such a dev would choose or guess. We can improve the non-core developer experience by defining and producing a set of standard libraries with intuitive names and interfaces. A userspace standard library will provide similar affordances to those available in common languages with larger user bases.
Several new libraries need to be defined. This will presumably be distributed via %yard.
/lib/string, https://github.com/sigilante/string (ready)/lib/vector, C++std::vector-style templating/lib/list, convenient list operations which are currently nonexistent (enumerate,zip,product, etc.)—maybe a general iterator type?/lib/datetime, https://github.com/sigilante/chronos (needs reworked)/lib/locale, https://github.com/sigilante/l10n (needs reworked)/lib/csv, proper CSV processing (unclear how it relates to current CSV tooling, which may be adequate)/lib/json, a convenience wrapper over current tooling/lib/decimal, a convenience wrapper over current tooling/lib/textwrap, perhaps just rolled into/lib/string/lib/math, combination of convenience wrappers and backported Saloon functionality to@r/lib/cmath, proof of concept for a simplecomplextype in Hoon/lib/fractions, rational numbers/lib/markdown, a compliant Markdown implementation/lib/curses, TUI materials/lib/file,pathlib+glob+filecmp+os.pathmaterials
Some minor changes are proposed to /sys.
- Namespace the parser components.
- Reimplement something like old file diff material but as tooling in
/lib/file. - Consider a Great Renaming of unintuitive arm names.
I like this idea. I also think a general iterator type could be useful. Maybe something like this: