shard-wiki/research/260614-squeak-pharo-deep-dive/findings.md

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).