09bd581 | plum

A statically typed, imperative programming language inspired by rust, python

09bd581 — Peter John 2026-07-21T02:00:46+05:30

docs: note nested-closure limitation in Known Gaps

Files changed (1) hide show

README.md CHANGED Viewed

@@ -353,3 +353,4 @@ Some things parse and type-check but don't compile to wasm yet — `plum-wasm-co
 - a closure literal used directly as a call argument only parses with a single-line body (`each(|v| v * 3)`); a multi-line indented body immediately followed by a closing `)` on the same line as the body's last statement (e.g. `each(|v|\n  v)`) does not yet parse — the external scanner doesn't emit a `DEDENT` at a closing bracket. Assigning the closure to a local first (`cb = |v|\n  v + offset` then `cb(...)` or `each(cb)`) does support a multi-line body and sidesteps this
 - a closure created via assignment (not passed directly as a call argument) and later called at a concrete non-`Int` type (`Float` or a class/pointer type) can hit a wasm runtime trap due to a signature-resolution gap in `call_indirect` dispatch; this does not affect closures over `Int`, or closures passed directly as call arguments at any type. Tracked as a separate follow-up task
 - a plain top-level named function (not a `|params| body` closure literal) cannot yet be used directly as a `fn(...)`-typed value (e.g. `each(double)`) — only closure literals are supported at closure-typed call sites today
+- a closure literal nested inside another closure's body is not supported (produces a clear compile error)