perry-runtime: Effect framework throws `TypeError: pipe is not a function` during `Schema.ts` module init (Effect end-to-end blocker, post-#685)

[proggeramlug]

Summary

After #685 closed the static params = params.slice() lowering bug in Schema.ts__init, the Effect end-to-end DoD repro from #321 makes it further into Schema.ts on perry 0.5.862 — but trips on a new uncaught throw:

TypeError: pipe is not a function
    at <anonymous>

Strict improvement (got ~132 more bytes into Schema.ts's init body) but still blocks the DoD.

Repro

mkdir effect-321 && cd effect-321
cat > package.json <<'JSON'
{ "name": "effect-321", "version": "0.0.0", "type": "module",
  "perry": { "compilePackages": ["effect"] } }
JSON
bun add effect@3.21.2

cat > test_bare.ts <<'TS'
console.log("[1] before");
import {} from "effect";
console.log("[2] after");
TS

perry compile test_bare.ts -o /tmp/out
/tmp/out
# stdout:  (nothing)
# stderr:  TypeError: pipe is not a function
#              at <anonymous>
# exit:    1

Bisection

lldb backtrace via b _exit / run / bt:

  * frame #0: libsystem_kernel.dylib`__exit
    frame #1: libsystem_c.dylib`exit + 68
    frame #2-#5: throw machinery (4 frames)
    frame #6: out_b`<unnamed> + 12144            ← inside Schema.ts__init body (was +12012 pre-#685)
    frame #7: out_b`<unnamed> + 2000
    frame #8: out_b`<unnamed> + 64
    frame #9: out_b`<unnamed> + 12272
   frame #10: out_b`_main + 1252                 ← `bl @ _main + 1248` = unlinked offset 0x770
   frame #11: dyld`start

_main + 1248 → unlinked offset 0x290 + 0x4E0 = 0x770 → relocation:

0x770 ARM64_RELOC_BRANCH26  _node_modules_effect_src_Schema_ts__init

Same module as #685, slightly further in. Frame #6 is +12144 (vs +12012 pre-#685, +132 bytes / 33 instructions of additional init body covered).

Throw-site analysis

Message format <prop> is not a function (no (kind). prefix) traces uniquely to crates/perry-runtime/src/object.rs:6521-6531 — the "real-object receiver, method-not-found anywhere in dispatch chain" catch-all (added by #648):

crate::error::js_throw_type_error_not_a_function(
    std::ptr::null(),
    0,
    method_name.as_ptr(),   // = "pipe"
    method_name.len(),
);

So during Schema.ts__init, codegen emitted js_native_call_method(<real-object>, "pipe", args) but the dispatch chain didn't find pipe on the receiver's class vtable, prototype, or field-stored closures.

Almost certainly: top-level class X extends Y.pipe(...)

Schema.ts is full of top-level class declarations that eagerly evaluate String$.pipe(...) (or Lowercased.pipe(...), etc.) as the base class. The first one is at line 4970:

export class Lowercased extends String$.pipe(
  lowercased({ identifier: "Lowercased" })
) {}

export class Uppercased extends String$.pipe(...) {}        // line 5003
export class Capitalized extends String$.pipe(...) {}        // line 5036
export class Uncapitalized extends String$.pipe(...) {}      // line 5069
export class Char extends String$.pipe(length(1, ...)) {}    // line 5079
export class Trimmed extends String$.pipe(...) {}            // line 5162
export class NonEmptyTrimmedString extends Trimmed.pipe(...) {}  // line 5182
export class NonEmptyString extends String$.pipe(...) {}     // line 5324
// ... ~30 more `class X extends Y.pipe(...)` patterns

String$ is itself defined as class String$ extends make<string>(AST.stringKeyword) {} (line 1230) — a class extending the result of a factory function call. In the Effect runtime, make<...>(...) returns a class whose prototype chain reaches Pipeable, so String$.pipe(...) resolves to the universal pipeArguments-based implementation.

In Perry, that lookup fails. Likely culprits:

• Class-method dispatch doesn't walk the extends factory() prototype chain. When the base is a function call rather than a named class, perry's class-id propagation may not register the inheritance link, so String$'s vtable doesn't include pipe from the factory-produced base.
• Cross-module pipeArguments doesn't get registered as a method on the result of make(). pipeArguments is imported from ./Pipeable.js and assigned into the prototype of base schemas, but if the assignment path goes through a shape Perry can't track, the method-table entry is missing.
• Class-id collision — same name (String, possibly aliased to String$ only in Schema.ts) resolves to a different class registration that doesn't have pipe.

What I tried for a standalone repro

A minimal mimic — class Base { pipe(...) {} }; class Derived extends make() {}; const X = Derived.pipe(fn); class Final extends X {} — runs clean. So the trigger needs more state than the surface pattern; consistent with #611 / #671 / #685 (each required the full Effect init prefix to repro).

Status snapshot for #321

Phase	v0.5.706	v0.5.795	v0.5.809	v0.5.862
Boots into main	❌ SIGSEGV	✅	✅	✅
Inits cleared before crash	—	25/362	308/362	308/362*
Crash module	Utils.ts	HashMap.ts	Schema.ts (early)	Schema.ts (~132 bytes later)
result: 42	—	—	—	—

* Same module as v0.5.809 but reaching deeper into the init body — Schema.ts itself is large enough that there's room for several sequential throw sites.

Notes for whoever picks this up

• The throw is from object.rs:6521 (real-object dispatch catch-all from Calling undefined as a function silently no-ops instead of throwing TypeError #648). Adding eprintln! of the receiver's class_id + the dispatch path tried before the throw would identify exactly where the inheritance lookup falls off.
• The class X extends Y.pipe(...) shape is the strongest hypothesis. Counter-test: comment out everything after Schema.ts line 4970 (or replace the String$.pipe(...) bases with Object or a no-pipe class) and see if the throw moves or goes away.
• Effect's Pipeable protocol is implemented in effect/src/Pipeable.ts — pipeArguments(self, args) walks varargs as a fold. Any class produced by make() (Schema.ts:1230's class String$ extends make<string>(AST.stringKeyword) {}) should have pipe installed via the standard Pipeable inheritance chain.

Refs #321, #685.

[proggeramlug]

Investigated this in a worktree session while landing the #712 defensive guard. The full fix is too invasive to bundle alongside #712, but here are the concrete root-cause findings for whoever picks this up.

Dispatch trace (via temporary eprintln! in object.rs::js_native_call_method)

Receiver of the failing pipe call:

• bits = 0x7ffd020000ad88a0 (POINTER_TAG, real object)
• class_id = 894
• parent_class_id = 0 ← missing parent edge in CLASS_REGISTRY
• gc_type = 2 (GC_TYPE_OBJECT)
• keys = [] (total 0)

Field-scan (object.rs:5884-5942) finds no pipe key. Vtable walk (object.rs:5944-5996) starts at 894, walks via get_parent_class_id — terminates after one step because the parent is 0. Class 894's own vtable has no pipe entry. Catch-all js_throw_type_error_not_a_function at object.rs:6526 fires.

Two layered blockers

(a) HIR drops extends Call(...)

crates/perry-hir/src/lower_decl.rs:646-706 (lower_class_decl) and :1620-1660 (lower_class_from_ast) only structurally match ast::Expr::Ident and ast::Expr::Member super-classes. The else-arms at :701-702 and :1655-1657 return (None, None, None) — both extends and extends_name unset.

crates/perry-codegen/src/codegen.rs:4422-4448 builds parent_pairs from class.extends_name. With extends_name = None, no (child_cid, parent_cid) is emitted; no js_register_class_parent call is generated. At runtime, CLASS_REGISTRY has no entry for child→parent.

The Effect Schema.ts patterns that hit this:

class String$ extends make<string>(AST.stringKeyword) {}   // CallExpr
class Lowercased extends String$.pipe(...) {}              // Member.Call(...)
class Trimmed extends String$.pipe(...) {}                  // 30+ similar
class NonEmptyTrimmedString extends Trimmed.pipe(...) {}    // chained

(b) Function.prototype = X assignment pattern

Effect's internal/effectable.ts:120-131:

function Base() {}
Base.prototype = CommitPrototype   // CommitPrototype spreads EffectPrototype with pipe()

Perry has no analogue for this. There is no js_register_class_prototype and no prototype-object-assignment lowering. The codegen treats the JS function as a regular function; instances of class X extends Base {} (which Effect's Schema relies on via various base-class chains) get no pipe inherited.

Why simple heuristics are unsafe

A "best-effort" fix that captures extends Y.method(...) as extends_name = Y would create wrong vtable chains: Y is a factory, not the parent — Y.method(...) returns some derived class. Linking the child to Y could surface methods from Y that aren't on the actual parent, or miss methods that are. Wrong inheritance is worse than missing inheritance.

The #687 ClassRef static-dispatch fallback (crates/perry-codegen/src/lower_call.rs:1785-1832) masks this for ClassRef receivers but not instance receivers — which is why minimal mimics of the Effect pattern run clean while the real Effect Schema.ts hits the throw.

Recommended fix sketch (multi-day)

1. HIR Class struct (crates/perry-hir/src/ir.rs:534-565): add extends_expr: Option<Box<Expr>>.
2. Lowering (lower_decl.rs both arms): when super-class is Call/New/etc, store the lowered expression in extends_expr.
3. Codegen: at each class declaration site in the module body (NOT in __perry_init_strings, since the extends expression depends on prior module statements being evaluated), emit:

   let __extends_val = <eval extends_expr>;
   js_register_class_parent_dynamic(CHILD_CID, __extends_val);
   

4. Runtime: new helper js_register_class_parent_dynamic(child_cid, value) that reads the class_id from value (via GcHeader for real objects, ClassRef tag for class references) and calls register_class(child_cid, parent_cid).
5. Function.prototype = X (separate, deeper): detect function Base() {}; Base.prototype = obj in HIR AssignExpr and either synthesize a class whose vtable holds obj's methods, or attach a side-table FUNCTION_PROTOTYPE_OVERRIDE: HashMap<func_ptr, obj_ptr> consulted by the vtable walk when a class inherits from such a function.

For Schema.ts → Effect.succeed(42) alone, items 1-4 are likely sufficient. Item 5 unlocks the broader Effect ecosystem (Stream, Layer, etc.) where virtually every Effect type uses the prototype-reassignment pattern.

Files of interest

• crates/perry-hir/src/lower_decl.rs:646-706 and :1620-1660 — extends lowering arms (drop CallExpr)
• crates/perry-codegen/src/codegen.rs:4422-4448 — parent_pairs emission (keyed off extends_name)
• crates/perry-codegen/src/lower_call.rs:1785-1832 — perry-codegen: (number).pipe is not a function during effect/Schema.ts__init — INT32-tagged class-ref receiver post-#685 (Effect end-to-end blocker) #687 ClassRef static-dispatch fallback (masks the gap for ClassRef receivers)
• crates/perry-runtime/src/object.rs:5944-5996 — vtable walk that terminates when parent=0
• crates/perry-runtime/src/object.rs:1538-1595 — register_class / lookup_class_method_in_chain chain helpers
• crates/perry-runtime/src/object.rs:6526 — the throw site (js_throw_type_error_not_a_function catch-all)

Note on perry-jsruntime rebuild

While investigating I hit a pitfall worth flagging: the auto-optimize cache's libperry_runtime.a is shadowed at link time by an older perry_runtime copy bundled inside libperry_jsruntime.a. After editing perry-runtime, you must also cargo build --release -p perry-jsruntime for the changes to reach the final binary. Without that rebuild, diagnostic eprintln! changes in perry-runtime won't appear in the test output and you'll think your prints aren't firing. Worth a separate issue.