58 lines
2.4 KiB
Markdown
58 lines
2.4 KiB
Markdown
---
|
|
id: LSN-0020
|
|
ticket: pbs-learn-to-discussion-lessons-migration
|
|
title: PBS Runtime Values, Identity, and Memory Boundaries Legacy Import
|
|
created: 2026-03-27
|
|
tags: [compiler, pbs, legacy-import, runtime, values, identity, memory]
|
|
---
|
|
|
|
## Context
|
|
|
|
Legacy import from `docs/compiler/pbs/learn/03. Runtime Values, Identity, and Memory Boundaries.md`.
|
|
|
|
This lesson preserves the runtime-facing mental model that keeps PBS lowering, diagnostics, and future optimization work aligned on aliasing, retention, and ownership.
|
|
|
|
## Key Decisions
|
|
|
|
### Value categories are explicit
|
|
|
|
**What:** PBS distinguishes copied payload values, identity-bearing values, and carrier-only values.
|
|
|
|
**Why:** Later lowering and diagnostics need a stable answer to whether a construct preserves aliasing, creates retention, or just transports an existing payload.
|
|
|
|
**Trade-offs:** The model is intentionally qualitative rather than layout-specific, which keeps it stable but less byte-accounting-friendly.
|
|
|
|
### Host boundary semantics remain explicit
|
|
|
|
**What:** Host interaction is stack-only across the boundary, but host-backed resources still count as identity-bearing on the PBS side.
|
|
|
|
**Why:** PBS needs a clean boundary without pretending that host ownership disappears once a value crosses into language semantics.
|
|
|
|
**Trade-offs:** This is semantically clean, but it requires implementers to avoid naive “stack-only means no ownership complexity” shortcuts.
|
|
|
|
## Patterns and Algorithms
|
|
|
|
- Treat scalars as copied payload without user-visible identity.
|
|
- Treat structs, services, and host-backed resources as identity-bearing.
|
|
- Treat tuples, `optional`, and `result` as carriers that do not create identity of their own.
|
|
- Interpret cost visibility semantically:
|
|
- allocation-bearing,
|
|
- retention-bearing,
|
|
- copy versus aliasing,
|
|
- host-boundary crossing,
|
|
- trap possibility.
|
|
- Keep future lifetime-control and concurrency surfaces out of `core-v1` unless explicitly claimed.
|
|
|
|
## Pitfalls
|
|
|
|
- Assuming carrier types create fresh identity.
|
|
- Confusing qualitative runtime guarantees with exact allocator or collector promises.
|
|
- Assuming stack-only host crossing eliminates host ownership concerns.
|
|
- Silently treating future-profile surfaces as current supported behavior.
|
|
|
|
## Takeaways
|
|
|
|
- PBS runtime contracts are qualitative on purpose.
|
|
- Identity, aliasing, and retention are the stable facts that matter most for maintenance.
|
|
- Host authority and PBS semantic identity can coexist without contradiction.
|