Skip to content

docs: follow the cl-prolog-kit / cl-dataflow-kit rename #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
takeokunn merged 1 commit into from
Aug 17, 2026
Merged

docs: follow the cl-prolog-kit / cl-dataflow-kit rename #2

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/src/project/production-readiness.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -165,10 +165,10 @@ derivations rather than separate CI jobs, so there is one command that
either passes or says exactly why not.

Nine further nerima-lisp org packages were evaluated for adoption over the
course of this refactor (`cl-dataflow`, `cl-parser-kit`, `cl-cli`,
course of this refactor (`cl-dataflow-kit`, `cl-parser-kit`, `cl-cli`,
`cl-tty-kit`, `cl-regex-kit`, `cl-history-kit`, `cl-date-kit`,
`cl-concurrent-kit`, `cl-host-kit`); see
[Architecture](../reference/architecture.md#why-not-cl-dataflow) and
[Architecture](../reference/architecture.md#why-not-cl-dataflow-kit) and
[Architecture](../reference/architecture.md#other-org-packages-evaluated-and-declined)
for the reasoning behind declining all nine as dependencies, and the one
place (`rt-getenv`/`rt-setenv`/`rt-unsetenv`'s POSIX name validation) where
Expand Down
8 changes: 4 additions & 4 deletions docs/src/reference/architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,14 +84,14 @@ more subsystems in a library that already has 125 files.
The depth ceiling for the org is 4. Adding a fourth dependency here would come
close enough to it to be worth discussing first.

### Why not cl-dataflow
### Why not cl-dataflow-kit

`cl-dataflow` (computation graphs, pipelines, state machines, effect
`cl-dataflow-kit` (computation graphs, pipelines, state machines, effect
boundaries) is an L3 sibling that looks adjacent to `reactive.lisp` and
`effects.lisp` on the surface. It is not a fit: both of those files implement
a specific low-level protocol by name -- Reactive Streams'
`on-subscribe`/`on-next`/`on-error`/`on-complete` and an algebraic-effect
handler stack -- that the cl-cc compiler emits code against. `cl-dataflow`'s
handler stack -- that the cl-cc compiler emits code against. `cl-dataflow-kit`'s
`define-pipeline`/`:node`/`:edge` model operates one layer up, at named-graph
orchestration. Adopting it here would mean wrapping its graph API to fake the
protocol shape downstream code already targets, which is exactly the kind of
Expand All @@ -111,7 +111,7 @@ timezone arithmetic has no consumer here; every clock read in this tree goes
through `rt-gettime-monotonic`, not a calendar. `cl-regex-kit` has no
string-pattern call site to replace.

`cl-concurrent-kit` is the same shape mismatch as `cl-dataflow` above: it is
`cl-concurrent-kit` is the same shape mismatch as `cl-dataflow-kit` above: it is
a bordeaux-threads-style portable primitive set, one layer up from what this
library needs. `sync.lisp`'s primitives are named `rt-*` because the
compiler back end emits calls to them by that exact name, not because this
Expand Down