Phase 6d: merge struct into property; storage follows use

`struct` and `property` had identical syntax and differed only in semantics, so
they are now one keyword: `property`. How a property is stored follows from how
it is used —

  - listed in a `model` or attached by `spawn`  -> an ECS component, kept in the
    engine's per-entity @S_/@H_ arrays and bound in queries (as before);
  - constructed with `new`                       -> a heap record with reference
    semantics (what `struct` used to be).

A program that declares only `property` records and functions — no `model`, no
`handler` — is not an ECS program: it gets record layouts and `new`, but no
entity storage, allocator, snapshot, or runtime splice. This is exactly the
shape of the Ludic compiler itself, whose Node/Tok/Buf/Val are now `property`.

Mechanics:
  - record layout (%Cmp_) now always emitted in the header (emit_head), so `new`
    works with or without the ECS; the per-entity arrays stay in
    emit_ecs_storage. %Str_ is gone — one layout prefix.
  - has_ecs() is now `has_systems() or has_models()`, not "any component"; a
    property alone no longer drags in the ECS runtime. Added has_models().
  - emit_new / member access / layout_ty / layout_node collapse onto find_comp.
    Dropped struct keyword, parse_struct, find_struct, is_struct_ty, N_STRUCT
    emission (the const stays at kind 0, the default node kind).

Migration done as two reseeds (the old compiler treats any component as ECS, so
it cannot see `property` records in the compiler source until has_ecs is fixed):
  A) teach the compiler property-as-record + fix has_ecs, keeping `struct`;
  B) migrate the compiler's own records to `property` and remove `struct`.

selfhost/tests/structs.ludic migrated (still prints 7 9 109 2 42). Vocabulary
drops `struct` from DECL (ludic_syntax.h, grammar, LudicTokens.kt). LANGUAGE.md
"Records" section rewritten. Reseeded (21613 lines); C-free fixpoint holds;
goldens identical; 17/17; vocab + doc-fences clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Orkun ÇAKILKAYA 2026-08-27 23:32:05 +03:00
parent 3fd599ce47
commit dc475b17c2
15 changed files with 4054 additions and 4378 deletions

View file

@ -5,16 +5,22 @@
const MAX_ENT: int = 1024
fn has_ecs() -> bool {
let i = 0
while i < len(prog) { let k = prog[i].kind; if k == N_COMP or k == N_SYS { return true }; i = i + 1 }
return false
}
fn has_systems() -> bool {
let i = 0
while i < len(prog) { if prog[i].kind == N_SYS { return true }; i = i + 1 }
return false
}
fn has_models() -> bool {
let i = 0
while i < len(prog) { if prog[i].kind == N_ARCH { return true }; i = i + 1 }
return false
}
# Does this program run the ECS? A property alone no longer answers that — the
# same `property` keyword also declares plain `new`-allocated records (the merged
# `struct`). A program uses the ECS when it has a handler or a model; a tool that
# only declares record types and functions does not, and gets no entity storage,
# allocator, snapshot or runtime splice.
fn has_ecs() -> bool { return has_systems() or has_models() }
fn emit_ecs_storage() -> void {
emith("@L_running = internal global i32 1\n")
@ -28,12 +34,10 @@ fn emit_ecs_storage() -> void {
let i = 0
while i < len(prog) {
let c = prog[i]
# per-entity storage for a property (its %Cmp_ layout is emitted in the
# header). Every property in an ECS program is a component today; a property
# used only via `new` would not need these, but no such program mixes the two.
if c.kind == N_COMP {
emith(sconcat("%Cmp_", sconcat(c.s, " = type { ")))
if len(c.kids) == 0 { emith("i32") }
let f = 0
while f < len(c.kids) { if f > 0 { emith(", ") }; emith(llty(c.kids[f].ty)); f = f + 1 }
emith(" }\n")
emith(sconcat("@S_", sconcat(c.s, sconcat(" = internal global [", sconcat(me, sconcat(" x %Cmp_", sconcat(c.s, "] zeroinitializer\n")))))))
emith(sconcat("@H_", sconcat(c.s, sconcat(" = internal global [", sconcat(me, " x i8] zeroinitializer\n")))))
}