Stdlib module mod.vit
This page is a wiki-style reference for one concrete stdlib file. It explains what the file owns, where it fits in the family, and how to decide whether this is the right surface to depend on.
mod.vit.Family: stdlib
Kind: aggregation module
Page style: this reference follows the same “encyclopedic card + portrait + usage contract” logic as the keyword pages, but for stdlib modules.
Summary
Overview
| Field | Value |
|---|---|
| Path | mod.vit |
| Family | stdlib |
| Kind | aggregation module |
| Line count | 79 |
| Declared procedures | 16 |
| Declared forms/picks | 2 |
`mod.vit` is a aggregation module inside the `stdlib` family. It should be read as one focused slice of the broader family responsibility: Top-level map of the Vitte standard library and the responsibilities owned by each family.
Purpose
This file should be chosen because of responsibility, not because its name “sounds close enough”. Inside the stdlib family, it carries one focused part of the contract and keeps that responsibility separate from neighboring concerns.
- Domain values start in `core` and `strings`.
- Grouped data moves through `collections` or `data`.
- Structured export goes through `json` and `encoding`.
- Filesystem or process interaction goes through `path`, `io`, `os`, or `sysinfo`.
- Explicit runtime coordination goes through `async`, `threading`, `kernel`, or `ffi`.
Top-level API inventory
| Surface | Items |
|---|---|
| Procedures | vector_new, vector_push, hashmap_new, hashmap_insert, io_read_file, io_write_file, io_append_file, io_file_exists, io_create_directory, io_is_file, io_is_directory, io_copy_file |
| Forms | Vector, HashMap |
| Picks | none declared at top level |
| Constants | none declared at top level |
Imported surfaces
vitte/stdlib/collections as coll use vitte/stdlib/io as io use vitte/stdlib/io/fileops.{ append_file, copy_file, create_directory, delete_directory, delete_file, file_exists, is_directory, is_file, list_directory, move_file, read_file, write_file } form Vector
How to use this module
Start by reading the file as an ownership boundary. Ask three questions: what enters this module, what stable types or procedures it exports, and what adjacent module should stay outside of it.
- Open the family page first to understand why this area of the stdlib exists.
- Read the source excerpt below to see the namespace, imports, and first declared surfaces.
- Check the neighbor list to avoid coupling this module with an adjacent responsibility by habit.
Source shape
space vitte/stdlib/mod
use vitte/stdlib/collections as coll
use vitte/stdlib/io as io
use vitte/stdlib/io/fileops.{ append_file, copy_file, create_directory, delete_directory, delete_file, file_exists, is_directory, is_file, list_directory, move_file, read_file, write_file }
form Vector<T> {
data: [T],
}
form HashMap<K, V> {
entries: [(K, V)],
}The excerpt is not meant to replace the file. It exists to make the module recognizable at first glance, the same way a Wikipedia infobox helps the reader orient before reading the whole article.
Integration boundaries
Within stdlib, this file should remain focused. If a future helper changes the host boundary, scheduling boundary, or data-shape boundary, it probably belongs in a neighbor module instead of being added here by convenience.
- Family responsibility: Top-level map of the Vitte standard library and the responsibilities owned by each family.
- Family architecture role: A realistic Vitte program usually starts in `core`, grows through `collections` or `data`, crosses textual boundaries with `json` or `encoding`, touches the host with `path` or `io`, and only then reaches system-facing families like `kernel`, `ffi`, `async`, or `threading`.