From 7d9dc46e1d4bc1d91b434dd06ed84490de89d0d0 Mon Sep 17 00:00:00 2001 From: takeokunn Date: Mon, 17 Aug 2026 21:47:37 +0900 Subject: [PATCH] docs: follow the cl-prolog-kit / cl-dataflow-kit rename nerima-lisp/cl-prolog was renamed to cl-prolog-kit (v1.5.0) and cl-dataflow to cl-dataflow-kit (v1.2.0). This repository does not depend on either, so nothing functional changes here -- these are the prose, comments and examples that cite them by name, which would otherwise read as pointing at repositories that no longer answer to those names. --- docs/src/project/production-readiness.md | 4 ++-- docs/src/reference/architecture.md | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/src/project/production-readiness.md b/docs/src/project/production-readiness.md index 0352b77..eb10692 100644 --- a/docs/src/project/production-readiness.md +++ b/docs/src/project/production-readiness.md @@ -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 diff --git a/docs/src/reference/architecture.md b/docs/src/reference/architecture.md index b17ef98..0208008 100644 --- a/docs/src/reference/architecture.md +++ b/docs/src/reference/architecture.md @@ -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 @@ -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