2026-06-14 18:28:06 +02:00
parent 4543f5dc43
commit 9b5defa6d8
3 changed files with 413 additions and 4 deletions
							
							
							
						
@@ -0,0 +1,199 @@
---
id: SHARD-WP-0004
type: workplan
title: "computational / interactive-knowledge systems research"
domain: whynot
repo: shard-wiki
status: active
owner: tegwick
topic_slug: whynot
created: "2026-06-14"
updated: "2026-06-14"
---
# SHARD-WP-0004 — computational / interactive-knowledge systems research
## Goal
Research systems **tuned to interactive usage of knowledge interacting with computation,
programming, and mathematics** — literate programming, computational notebooks, live-
coding REPLs, and image-based/moldable programming environments — to extract patterns for
shard-wiki's treatment of **executable / computational / live page content** and
**one-source-many-projections**.
This workplan is more *exploratory* than the engine batch (`SHARD-WP-0003`): these systems
are mostly **not candidate shards**, they are **design prior art** for questions the
modern-tool dives raised but did not answer — what a "page" is when it is a *live
computation*, how *computed results* carry provenance/reproducibility, and how one source
projects into multiple rendered forms. Outputs feed the **page model** and the **addressing/
navigation** threads of the adapter contract, and may produce a dedicated synthesis
("the computational page model").
Each subject follows the dive tradition (`research/<yymmdd>-<slug>-deep-dive/` with
`README.md` + `findings.md`) but the catalog yield is expected to be **fewer new UCs and
more page-model / projection design notes**. Promote UCs only where a genuine new
*orchestration* scenario appears; otherwise enrich (UC-44 compose-by-reference, UC-54
query-defined page, UC-55 non-Markdown content, UC-32 transclusion) and log page-model
implications for `SHARD-WP-0002` T12/T16.
## Context
- Page-model thread: `SHARD-WP-0002` T12 (structured/typed/computed payload, query-defined
  pages, non-Markdown content) and T16 (addressing, transclusion, dimensional/query nav).
- Relevant existing UCs: UC-44 (compose-by-reference / EDL manifest), UC-54 (query-defined
  dynamic page), UC-55 (non-Markdown content), UC-32 (transclusion), UC-63 (derived index).
- Synthesis: `research/260614-shard-spectrum-synthesis/findings.md` (the spectra a
  "computational content" capability would extend).
**Framing question carried across all subjects:** *Can a shard-wiki page be a live
computational artifact — a source that is woven/tangled/evaluated into rendered forms —
and if so, how do projection, transclusion, provenance, and the adapter contract treat the
source, the kernel/environment, and the computed output?*
**Non-goal:** Implement a kernel or execution layer. Research + design notes only; any
"executable content" remains mechanism-over-policy and capability-gated.
---
## Literate Programming — Knuth's WEB / weave / tangle
```task
id: SHARD-WP-0004-T1
status: todo
priority: high
```
Deep-dive **Donald Knuth's WEB** and the **weave/tangle** model of **literate
programming**. The keystone pattern: **one WEB source → `weave` (typeset documentation)
+ `tangle` (compilable code)** — *one source, two projections* — plus **named code
chunks** referenced/embedded across the document (transclusion-like). This is the deepest
ancestor of shard-wiki's **projection** and **transclusion** ideas applied to
*executable* content. Map to UC-44 (compose-by-reference), UC-32 (transclusion), and the
projection model; log "source-with-multiple-projections" as a page-model pattern for T12.
## Mathematica Notebooks
```task
id: SHARD-WP-0004-T2
status: todo
priority: medium
```
Deep-dive **Mathematica Notebooks** (the `.nb` format and cell model). The original
computational notebook: **cells** (input/output/text), an **expression-tree** document,
symbolic evaluation, interactive results inline. Study the document format, output
provenance, and reproducibility. Enrich UC-54 (query/computation-defined content), UC-55
(rich computed output); page-model notes on **computed-output cells** for T12.
## Jupyter Notebooks
```task
id: SHARD-WP-0004-T3
status: todo
priority: high
```
Deep-dive **Jupyter Notebooks**: the **`.ipynb` JSON** model (cells: markdown / code /
output), **kernels**, embedded outputs, and execution-count/provenance. The dominant
computational document — and a concrete **non-Markdown, partially-executable content
type** with **embedded computed outputs** that carry (fragile) provenance. Highly relevant
to a "computational shard" and to output reproducibility. Enrich UC-54, UC-55, UC-59
(lossy capture of rich outputs); consider a new UC for **attaching/projecting a notebook
with computed-output provenance**; feed T12/T15.
## Processing.org and Processing.js
```task
id: SHARD-WP-0004-T4
status: todo
priority: low
```
Deep-dive **Processing.org** (creative-coding) and especially **Processing.js**
(browser-run sketches). The pattern: **the sketch *is* the document** — a program whose
rendered form is live visual output, runnable in the browser. Study "program-as-page" and
client-side live rendering. Notes on **executable/visual content rendered at view time**
for the page model (UC-54/55).
## Strudel.cc — live-coding REPL
```task
id: SHARD-WP-0004-T5
status: todo
priority: low
```
Deep-dive **Strudel.cc** (the JS port of TidalCycles): a **browser REPL** for live-coding
music/patterns. The pattern: **code as a live, evaluated performance**; a page whose
"content" is a running pattern. Study the REPL/live-evaluation model and pattern language.
Notes on **live-evaluated, time-based content** and the limits of static projection
(UC-54/55; graceful degradation to a snapshot).
## Squeak Smalltalk
```task
id: SHARD-WP-0004-T6
status: todo
priority: medium
```
Deep-dive **Squeak Smalltalk**: the **image-based** live-object environment — "everything
is a live object," the **image as a persistent world**, Morphic. The pattern:
**knowledge-as-live-objects** rather than files, and an environment with no
file/document/app boundary. Contrast hard with shard-wiki's files-canonical stance
(design-bug boundary), but mine it for **live-object / moldable** ideas. Page-model and
boundary notes (image-as-store is the anti-pattern; the live-object inspection is the
inspiration).
## Glamorous Toolkit — moldable development
```task
id: SHARD-WP-0004-T7
status: todo
priority: high
```
Deep-dive **Glamorous Toolkit** (on Pharo): **moldable development** — **custom views/
inspectors per object/domain**, a notebook + IDE where the *environment adapts to the
knowledge*. The pattern: **many co-equal, domain-specific views over the same live
objects** — a striking parallel to the ZigZag dimensional model (UC-47/48) and to
"query-defined / computed views" (UC-54). The strongest source for **moldable, multi-view
projection** of knowledge. Enrich UC-47/48 (dimensional/multi-view), UC-54; feed T16.
## Pharo
```task
id: SHARD-WP-0004-T8
status: todo
priority: low
```
Deep-dive **Pharo**: the modern Smalltalk that GT is built on — live image, reflective
environment, the substrate for moldable tools. Largely **context for T6/T7** (Squeak
lineage → Pharo → Glamorous Toolkit); keep brief unless it surfaces distinct page-model
ideas. May be folded into the GT memo if thin.
---
## Acceptance criteria
- Each of T1–T8 has a `research/<yymmdd>-<slug>-deep-dive/` dir with `README.md` +
  `findings.md` (or a justified merge, e.g. Pharo folded into GT), framed by the carried
  question above.
- `spec/UseCaseCatalog.md` updated **where a genuine orchestration UC appears**; otherwise
  enrichments to UC-32/44/54/55 and explicit **page-model / projection design notes**
  recorded in findings for `SHARD-WP-0002` T12/T16.
- `research/README.md` and `SCOPE.md` updated; each dive committed + state-hub-synced.
- **After the batch:** produce a short synthesis — *"the computational page model"* —
  consolidating literate-programming projection, notebook computed-output provenance, and
  moldable multi-view, with a recommendation on whether shard-wiki needs an **executable/
  computational content capability** (and how it stays mechanism-over-policy + capability-
  gated + degradable to a static snapshot).
## Suggested task order
Conceptual keystones first: **T1 Literate Programming → T3 Jupyter → T7 Glamorous
Toolkit**, then **T2 Mathematica → T6 Squeak (+ T8 Pharo)** for lineage, then the live/
visual REPLs **T4 Processing → T5 Strudel**. Close with the "computational page model"
synthesis.
</content>