coulomb/shard-wiki
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

research: Squeak & Pharo deep dive (image-based Smalltalk); SHARD-WP-0004 T6+T8

Browse Source 
Combined memo (justified merge). The image = purest 'live' end; hardens
the image-is-not-a-store boundary (export->files only), generalizing
'attach files not the kernel/image'. Pharo Tonel/Iceberg confirms even
image traditions externalize to git text. Names the live<->snapshot
projection axis (T16). Boundary/enrichment-only, no new UC. Marks T6+T8 done.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Bernd Worsch
2026-06-14 23:54:48 +02:00
parent 4acadacfee
commit 56b6cdd110
6 changed files with 207 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
SCOPE.md
View File

@@ -22,7 +22,7 @@ Learnings update both SCOPE and INTENT where necessary.
| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag + Roam + Obsidian + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) + Trilium + Wiki.js + Federated Wiki + Wikibase + git-forge wikis + TiddlyWiki + ikiwiki + Quip + MojoMojo + Oddmuse + UseModWiki deep dives & shard-spectrum synthesis (`research/260614-*/`) |
| Demand | NetKingdom integration asks captured, not yet negotiated |
| Spec | Architecture blueprint drafted; UseCaseCatalog 84 UCs from research; PRD/TSD scaffolds |
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract); `SHARD-WP-0003` **done** (9 engine dives complete); `SHARD-WP-0004` active (8 computational-knowledge dives: T1 literate programming, T2 Mathematica, T3 Jupyter, T7 Glamorous Toolkit done) |
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract); `SHARD-WP-0003` **done** (9 engine dives complete); `SHARD-WP-0004` active (8 computational-knowledge dives: T1 literate programming, T2 Mathematica, T3 Jupyter, T6 Squeak + T8 Pharo (merged), T7 Glamorous Toolkit done) |
## In Scope (today)

33
research/260614-squeak-pharo-deep-dive/README.md Normal file
View File

@@ -0,0 +1,33 @@
# 260614 — Squeak & Pharo (image-based Smalltalk) deep dive
Date: 2026-06-14 · Source: **SHARD-WP-0004 T6 (Squeak) + T8 (Pharo)** — combined memo
(justified merge: both are image-based Smalltalks; Pharo is T8's thin "context for T6/T7").
## What this is
A deep dive into the **image-based live-object** environment — Squeak and Pharo (the
substrate Glamorous Toolkit T7 runs on): the **image** as a persistent world of live objects
with **no file/document/app boundary**, the live **inspector**, and Pharo's retreat to
**code-as-text in git** (Tonel/Iceberg).
## Why it matters
- The **purest "live" end** of the batch's spectrum (literate source → notebook snapshot →
GT/Lepiter live-over-files → **image: everything live**). Names the **live↔snapshot** axis
the projection model (T16) must carry.
- Hardens the **image-is-not-a-store** boundary (opaque monolithic non-diffable blob; no
page identity/history/provenance) — generalizes "attach files, not the kernel/image"
(UC-84, T7) into a named binding boundary (T14).
- Pharo **confirms** the resolution: even image traditions externalize to **git-versionable
text** (Tonel) to version/collaborate — files-canonical from the Smalltalk side.
## Yield
- **No new UC** (boundary / design prior art; covers T6 and T8). Boundary for UC-34/35/79;
links UC-83/84 (live→snapshot), UC-54/47/48 (live-object inspection), UC-76/79 (Tonel/git).
## Contents
| Path | Role |
|------|------|
| `findings.md` | The image & live objects, the image-as-store anti-pattern, Pharo Tonel/Iceberg→git, INTENT mapping, UC disposition (enrichment-only), architecture notes (T14 boundary, T16 live↔snapshot axis) |

141
research/260614-squeak-pharo-deep-dive/findings.md Normal file
View File

@@ -0,0 +1,141 @@
# Squeak & Pharo (image-based Smalltalk) — deep dive (findings)
**Date:** 2026-06-14 · **Source:** SHARD-WP-0004 **T6 (Squeak)** + **T8 (Pharo)** — combined
(justified merge: both are image-based Smalltalks; Pharo is T8's "context for T6/T7," kept
brief per the workplan). · **Subject:** the **image-based live-object** environment and what
it teaches (and warns) about shard-wiki's page model.
## Why this dive (and why merged)
Squeak (1996, the Alan Kay/Ingalls lineage) and Pharo (2008 fork, the substrate **Glamorous
Toolkit** T7 runs on) are the same idea: **a persistent world of live objects, the "image,"
with no file/document/application boundary.** They are **not candidate shards** — they are
the **anti-pattern boundary** for shard-wiki's files-canonical stance *and* the inspiration
behind moldable inspection (T7). T8 (Pharo) is folded here as the workplan allows: its
distinct contribution over Squeak (Tonel/Iceberg file-based code → git) is the one piece that
*does* touch our concerns, covered in §3.
## 1. The image: knowledge-as-live-objects
- A Smalltalk **image** is a serialized snapshot of the **entire object memory** — every
object, class, tool, window, and the running program state — persisted as one binary file
(`.image` + `.changes` log). You resume exactly where you left off.
- **"Everything is a live object"**: code, data, UI (Morphic), the debugger, the inspector —
all are objects you can open, message, and modify *in place*, while running. There is **no
edit/compile/run cycle** and **no document-vs-app distinction**.
- The **inspector** lets you open any object and explore/modify its state live — the direct
ancestor of GT's moldable inspector (T7), but generic rather than domain-molded.
This is the **purest "live" end** of the spectrum the whole batch traverses: literate source
(static) → notebook captured output (snapshot) → GT/Lepiter (live results over files) →
**image (everything live, nothing inherently a file).**
## 2. The boundary: image-as-store is the anti-pattern
The image directly **contradicts** shard-wiki's design constraints, which is exactly why it's
worth recording as a hard boundary:
- **Opaque, monolithic, non-diffable.** The image is one big binary blob of entangled live
state — no per-page identity, no text diff, no mergeable history, no provenance per unit.
It violates *union-without-erasure granularity*, *Markdown-first*, and *git-addressable
coordination*.
- **No stable addressable "page."** Knowledge is an object graph in memory, not addressable
documents — there is nothing to attach at page granularity without an export step.
- **History is a `.changes` log**, a serial source-change stream, not a content history.
**Conclusion (boundary recorded):** an image is **not a shard and not a store**. This is the
generalized form of the rule already hit at Jupyter (UC-84) and GT (T7): *attach the
exported files, never the live image/kernel.* The image can only participate via an **export
projection** (objects/code → files), which is a **derivation-projection** (T1) that
**degrades the liveness to a static snapshot**.
## 3. Pharo's twist: code-as-files (Tonel) → git (the one actionable bit)
Pharo (T8) matters precisely where it **retreats from pure-image**:
- **Tonel / FileTree** serialize each class/method as **plain-text files** in a directory,
and **Iceberg** manages those files as a **git repository** — so Pharo code lives in git as
text, diffable and mergeable, *outside* the image.
- This is the **same move** as Lepiter (T7), nbstripout/Jupytext (T3), and ikiwiki source
(UC-79): **the durable, attachable artifact is the file representation; the live
environment is a layer above it.** It confirms our stance from the *Smalltalk* side: even
the most image-centric tradition externalizes to **git-versionable text** to collaborate.
So Pharo adds **no new page-model idea** beyond "image-based environments still externalize
to git text" — exactly the "keep brief / fold" expectation. Its value is **confirming the
boundary resolution**: attach the **Tonel/git source**, treat the image as live-only.
## 4. INTENT mapping
### Inspiration (keep)
- **Live-object inspection** is the seed of moldable views (T7/UC-54): the *idea* that any
unit can be opened and explained interactively. shard-wiki adopts this as **projection/
view**, not as a storage model.
- **Resume-where-you-left-off** liveness names the far end of the **live↔snapshot** axis the
contract must place every computed/projected view on (UC-83/84): the more live the source,
the more its attached form is a **degrading snapshot**.
### Boundary (enforce — design-bug if violated)
- **Image-as-store is a design-bug boundary.** Never model an image (or any monolithic live
memory blob) as a shard/store; participate only via **export → files** (a degrading
derivation-projection). Generalizes "attach files, not the kernel/image" (UC-84, T7).
### Confirmation (Pharo)
- Even pure-image traditions externalize to **git-versionable text** (Tonel/Iceberg) to
version and collaborate — reinforcing **files-canonical + git coordination** as the
durable substrate; the live environment sits above it.
## 5. UC disposition (enrichment-only — no new UC)
| Mechanism (findings §) | Catalog UC / thread |
|------------------------|---------------------|
| Live-object inspector = generic ancestor of moldable views (§1) | links UC-54, UC-47/48 (T7) |
| Image = opaque monolithic non-diffable blob; not a page/store (§2) | **boundary** for UC-34/UC-35/UC-79 (granularity, identity, files-canonical) |
| Image participates only via export→files = degrading derivation-projection (§2) | links UC-83, UC-84 (live→snapshot) |
| Pharo Tonel/Iceberg: code-as-text in git (§3) | links UC-79, UC-76 (git-canonical text) |
| `.changes` = serial source-change log, not content history (§1) | links UC-36 (history shape) |
Both Squeak and Pharo are **design prior art / boundary**, not candidate shards → **no new
UC**. They sharpen the **live↔snapshot** axis and harden the **image-is-not-a-store**
boundary; Pharo confirms even image traditions externalize to git text.
## 6. Architecture notes for SHARD-WP-0002
- **T14 (attach binding):** record the **image-is-not-a-store** boundary explicitly — a
monolithic live-memory blob is never an attach target; participation is via **export→files**
only. Generalize the "attach files, not the kernel/image" rule (UC-84, GT T7) to a named
boundary in the binding taxonomy.
- **T16 (projection):** add the **live↔snapshot** axis to the projection model — every
computed/projected view sits somewhere between "live (re-derivable on demand)" and "static
snapshot," and the more live the source, the more its attached form must be a clearly-
marked degrading snapshot.
- **T11/T12:** the live-object inspector is the *inspiration* for the moldable view registry
(T7), not a storage shape; nothing new to the page model itself.
## 7. Open questions
1. Is **live↔snapshot** an explicit, first-class metadata axis on every projection (so the
union can label "this view was live / is a snapshot from time T"), or implicit per
capability? (Recurs across UC-83/84, GT, Mathematica `Dynamic`, Strudel T5.)
2. Do we ever ingest a Smalltalk project by attaching its **Tonel/git** repo as an ordinary
git-text shard (no Smalltalk-specific adapter needed), confirming the boundary resolution?
## 8. Sources
- Squeak: `squeak.org`, the *Back to the Future* (Squeak) paper (Ingalls et al.), Morphic;
image/`.changes` model.
- Pharo: `pharo.org`, **Tonel** format, **Iceberg** (git integration), FileTree.
- prior: `research/260614-glamorous-toolkit-deep-dive/` (moldable inspector, Lepiter, T7);
`research/260614-jupyter-deep-dive/` (live→snapshot boundary, UC-84).
## 9. Traceability
**No new UC** (boundary / design prior art; covers **T6 Squeak** and **T8 Pharo** in one
justified-merge memo). Boundary hardened for: UC-34/UC-35/UC-79 (image-is-not-a-store);
links UC-83/UC-84 (live→snapshot), UC-54/UC-47/UC-48 (live-object inspection → moldable
views), UC-76/UC-79 (Pharo Tonel/git text), UC-36 (`.changes` history shape). Architecture
cross-refs: SHARD-WP-0002 T14 (image-is-not-a-store boundary; export→files only), T16
(live↔snapshot projection axis).

1
research/README.md
View File

@@ -41,3 +41,4 @@ when multiple files or sources are involved. Findings here inform `spec/` and
| 2026-06-14 | `260614-jupyter-deep-dive/` | Jupyter Notebooks — `.ipynb` JSON cells + embedded computed outputs with fragile execution provenance; derived output stored *inside* the source; non-Markdown/lossy; kernel = capability; SHARD-WP-0004 T3; UC-84 |
| 2026-06-14 | `260614-glamorous-toolkit-deep-dive/` | Glamorous Toolkit (moldable development on Pharo) — `gtView` open set of co-equal type-keyed computed views (none canonical) = moldable view registry; Lepiter live notebook over git files; SHARD-WP-0004 T7; enrichment-only (UC-47/48/54) |
| 2026-06-14 | `260614-mathematica-deep-dive/` | Mathematica Notebooks — the original computational notebook (`.nb` = a Wolfram expression); nestable cell groups, structured re-evaluable outputs, `Manipulate` live widgets, CDF; confirms UC-84 notebook shape is a genus; SHARD-WP-0004 T2; enrichment-only (reinforces UC-84; UC-54/55) |
| 2026-06-14 | `260614-squeak-pharo-deep-dive/` | Squeak & Pharo (image-based Smalltalk) — the live-object image (purest "live" end); image-is-not-a-store boundary (export→files only); Pharo Tonel/Iceberg externalizes code to git text; names the live↔snapshot projection axis; SHARD-WP-0004 **T6 + T8** (merged); boundary/enrichment-only, no new UC |

28
spec/UseCaseCatalog.md
View File

@@ -2458,6 +2458,34 @@ projection. Architecture logged for `SHARD-WP-0002` (T12/T11/T15/T16): nestable
outline + typed structured outputs, structured-re-evaluable-value opacity point, CDF
reduced-capability projection.
### squeak / pharo mapping
(Boundary dive — **no new UC**; design prior art, covers **T6 Squeak + T8 Pharo** in one
justified-merge memo. Source: the **Squeak & Pharo deep dive**,
`research/260614-squeak-pharo-deep-dive/findings.md`.)
| Squeak/Pharo mechanism (findings §) | Catalog UC / thread |
|-------------------------------------|---------------------|
| Live-object inspector = generic ancestor of moldable views (§1) | links UC-54, UC-47/48 |
| Image = opaque monolithic non-diffable blob; not a page/store (§2) | **boundary** for UC-34/UC-35/UC-79 |
| Image participates only via export→files = degrading derivation-projection (§2) | links UC-83, UC-84 (live→snapshot) |
| Pharo Tonel/Iceberg: code-as-text in git (§3) | links UC-79, UC-76 |
| `.changes` = serial source-change log, not content history (§1) | links UC-36 |
Note: Squeak and Pharo are the **image-based live-object** tradition — a persistent world of
live objects (the "image") with **no file/document/app boundary** — and they serve shard-wiki
as both **inspiration** (the live inspector is the ancestor of GT's moldable views, UC-54/
UC-47/48) and a **hard boundary**. The image is an **opaque, monolithic, non-diffable blob**
with no page identity, history, or provenance, so **image-as-store is a design-bug boundary**:
it participates only via **export→files** (a degrading derivation-projection), the
generalized form of "attach files, not the kernel/image" (UC-84, GT T7). **Pharo** confirms
the resolution from the inside — even this tradition externalizes code to **git-versionable
text** (Tonel/Iceberg), reinforcing files-canonical + git coordination (UC-76/UC-79). They
name the **live↔snapshot** axis the projection model must carry (the purest "live" end of the
batch's spectrum). **No new UC.** Architecture logged for `SHARD-WP-0002` (T14/T16):
image-is-not-a-store binding boundary (export→files only); a live↔snapshot axis on every
projection.
---
## Open questions

4
workplans/SHARD-WP-0004-computational-knowledge-systems.md
View File

@@ -139,7 +139,7 @@ Notes on **live-evaluated, time-based content** and the limits of static project
```task
id: SHARD-WP-0004-T6
status: todo
status: done
priority: medium
state_hub_task_id: "50723598-7e21-4aaf-8f26-463cabc4e2d7"
```
@@ -172,7 +172,7 @@ projection** of knowledge. Enrich UC-47/48 (dimensional/multi-view), UC-54; feed
```task
id: SHARD-WP-0004-T8
status: todo
status: done
priority: low
state_hub_task_id: "b3a862d0-6980-411a-b41c-dd3592a39c52"
```