5a9e763 | plum | pyrossh

git clone https://git.pyrossh.dev/plum

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

5a9e763 — Peter John 2026-09-03T14:25:26+05:30

feat(libs/std): ship List.chunk/partition; add List.toStr; root-cause the last self-nesting bug

Files changed (2) hide show

README.md +2 -1
libs/std/list.plum +82 -17

README.md CHANGED Viewed

@@ -390,4 +390,5 @@ Some things parse and type-check but don't compile to wasm yet — `plum-wasm-co
 - interpolating a `Float` value in a string (`Str`/`Int`/`Bool` interpolation, and plain non-interpolated literals, all compile) — correct decimal formatting of a float is a substantial separate undertaking (something like Grisu/Ryu), scoped out for now
 - The generic-field-type gap that used to block `libs/std`'s real `List[T]`/`Node[T]` from compiling at all (a class/enum-variant field declared with a concrete instantiation of another generic type, e.g. `Node.next: Option[Node]`) is fixed — `List[T]`'s methods (`get`/`length`/`add`/`set`/`removeAt`/`remove`/`clear`/`reverse`/`each`/`map`/`reduce`/`sort`/`join`, including its `Stringable`-bounded dispatch) are exercised directly, at their real generic type, by the `test` blocks at the bottom of [`libs/std/list.plum`](libs/std/list.plum) itself (run via `plum test libs/std/list.plum`) — not a non-generic stand-in.
-- `Map[K, V]` previously hit a *different* bug here: a top-level function whose own declared return type was a fully-concrete generic instantiation (e.g. `fun makeMap() -> Map[Str, Int] = ...`) caused monomorphization to eagerly (and incorrectly) attempt to specialize an unrelated generic type's method (`Option.filter`) at an unresolved type variable, producing a spurious `expected Option, found Option$V` type error even though `filter` was never called anywhere in the program. Root cause: `maybeRewriteReturn` (in `plum-checker/src/monomorphize.rs`) treated ANY return type merely NAMING a known generic class/enum as still-unresolved and in need of rewriting from the body's inferred tail type — even when that name already carried concrete type args (`List[Str]`, `Map[Str, Int]`), clobbering an already-correct declared return type with a stale, unmangled one inferred through tables monomorphization hadn't finished refreshing yet. Fixed by only treating a BARE reference (no `[...]` at all, e.g. `-> Box`) as needing that rewrite; a companion fix pre-resolves every ordinary (non-generic) fn/method's signature into the type tables before any body rewriting begins, so cross-file call order no longer matters. `Map`'s `map` method (needing two new generic params nested inside a closure's return type) remains genuinely unimplemented, same limitation as `Option.andThen`
+- `Map[K, V]` previously hit a *different* bug here: a top-level function whose own declared return type was a fully-concrete generic instantiation (e.g. `fun makeMap() -> Map[Str, Int] = ...`) caused monomorphization to eagerly (and incorrectly) attempt to specialize an unrelated generic type's method (`Option.filter`) at an unresolved type variable, producing a spurious `expected Option, found Option$V` type error even though `filter` was never called anywhere in the program. Root cause: `maybeRewriteReturn` (in `plum-checker/src/monomorphize.rs`) treated ANY return type merely NAMING a known generic class/enum as still-unresolved and in need of rewriting from the body's inferred tail type — even when that name already carried concrete type args (`List[Str]`, `Map[Str, Int]`), clobbering an already-correct declared return type with a stale, unmangled one inferred through tables monomorphization hadn't finished refreshing yet. Fixed by only treating a BARE reference (no `[...]` at all, e.g. `-> Box`) as needing that rewrite; a companion fix pre-resolves every ordinary (non-generic) fn/method's signature into the type tables before any body rewriting begins, so cross-file call order no longer matters. `Option.andThen`/`Result.map`/`Result.mapErr` (a single extra generic, possibly nested inside a closure's return type) are now implemented and working. `Map`'s `map` method specifically (needing TWO new generic params nested inside a closure's return type, on a class rather than an enum) remains genuinely unimplemented — a distinct pair of gaps (a generic method's body never gets its own extra generics substituted, and closure-argument inference doesn't use the callee's declared param types as a hint) documented in code and project memory
+- A generic class/enum method whose return type nests that SAME class/enum inside itself (`List[T].chunk(self) -> List[List[T]]`) used to stack-overflow the compiler for every program merely importing the class, whether or not anything called the method — fixed; `List.chunk`/`List.partition` now ship and work as a working example of the pattern (build any inner `List[T]` value via an EXISTING ordinary method, e.g. `self.sublist(...)`, never a second bare `List(...)` construction in the same body, which is ambiguous with the method's own return-type fallback)

libs/std/list.plum CHANGED Viewed

@@ -373,24 +373,52 @@ type List[T: Stringable](Stringable) =
   # (`List`) nested inside itself as a method's own return type. This used to
   # be an unconditional stack-overflow landmine for the WHOLE COMPILER (see
   # `plum-checker/src/monomorphize.rs`'s `isSelfNested`/`methodMentionsTemplate`
-  # doc comments for the full fix) — that danger is now FIXED (2026-09-02),
+  # doc comments for the full fix) — that danger is now FIXED (2026-09-02).
+  #
+  # A second, more contained bug surfaced once past that: two SEPARATE bare
-  # verified: a program merely `import`ing `std/list` with these methods
+  # `List(head: None, tail: None, size: 0)` constructions in the SAME method
-  # DEFINED no longer hangs/crashes regardless of whether anything calls
-  # them. `chunk`/`partition` THEMSELVES are still not implemented, though —
-  # actually CALLING them still hits a second, more contained bug: the
-  # specialized `add` method on the resulting `List[List[T]]` (e.g.
+  # body — one for the OUTER `result: List[List[T]]` (matching this
-  # `List$List$Int`) gets registered with a WRONG/confused parameter type
+  # method's own declared return type) and one for an INNER per-chunk
-  # (`expected List$Int, found Int` and, inconsistently, `expected List$Int,
+  # `piece: List[T]` — are ambiguous to `resolveClassInstantiation`'s
+  # `current_return_type` fallback: since `List[T]` and `List[List[T]]` both
+  # have exactly ONE generic argument, the fallback (which only ever
+  # compares ARITY, not identity) can't tell "this bare construction IS the
+  # function's own return value" apart from "this is some OTHER, unrelated
-  # found List$List$Int` for the very same key, across different reported
+  # nested construction of the same template that happens to need the same
-  # call sites) — root cause not yet found; suspected signature-registration
-  # aliasing between a self-nested specialization and its own inner
-  # specialization, possibly compounded by both keeping the SAME bare method
+  # arity" — so `piece` was silently resolved to the SAME type as `result`
+  # (`List$List$Int` instead of `List$Int`), corrupting its own `add` calls.
+  # Worked around by building `piece` via `self.sublist(...)` instead of a
-  # name (`specializeFn` never mangles an ordinary method's own name).
+  # second bare construction — `sublist` is an ordinary method already
+  # unambiguously resolved through the RECEIVER's own (already-correct)
+  # binding, no `current_return_type` guessing involved at all.
+  fun chunk(self, size: Int) -> List[List[T]] =
+    result := List(head: None, tail: None, size: 0)
-  fun chunk(self) =
+    if size <= 0
+      return result
-    todo
+    i := 0
+    n := self.length()
+    while i < n
+      result.add(self.sublist(i, i + size))
+      i = i + size
+    return result
+  # Splits into two lists: elements `predicate` holds for, then the rest —
+  # in that order. Returns them as a 2-element `List[List[T]]` (`[matched,
+  # unmatched]`) since this language has no tuple type. Deliberately built
+  # from `self.retain(predicate)`/`self.reject(predicate)` rather than two
+  # local `matched`/`unmatched := List(head: None, ...)` bare constructions
+  # — see `chunk`'s doc comment above for exactly why that would be
+  # ambiguous (`matched`/`unmatched` need `List[T]`, but a bare
+  # construction here would resolve via `current_return_type` fallback
+  # against THIS method's own `List[List[T]]` return instead, same arity
+  # coincidence). `retain`/`reject` are each already unambiguous (single
+  # bare construction per method body, matching their own single-level
-  fun partition(self) =
+  # return type).
+  fun partition(self, predicate: fn(T) -> Bool) -> List[List[T]] =
+    result := List(head: None, tail: None, size: 0)
+    result.add(self.retain(predicate))
+    result.add(self.reject(predicate))
-    todo
+    return result
   # Grouping by an arbitrary key type would need its own generic param
   # (`groupBy<K>(keyFn: fn(T) -> K) -> Map[K, List[T]]`) resolved from a
@@ -421,6 +449,21 @@ type List[T: Stringable](Stringable) =
           break
     res.toStr()
+  # `List[T: Stringable](Stringable)` declared implementing `Stringable`
+  # from the start but never actually defined `toStr` — harmless for a
+  # PLAIN `List[Int]`/`List[Str]`/etc (nothing needs to call `.toStr()` on
+  # the LIST ITSELF, just on its elements, which `join` above already
+  # does), but a genuine gap the moment a `List` is used AS another
+  # `List`'s own ELEMENT type (`List[List[T]]`) — the OUTER list's eagerly-
+  # compiled `join`/`toStr` calls `.toStr()` on each element, and an inner
+  # `List[T]` element had no such method to call, failing to compile with
+  # "unknown method 'List$T.toStr'" even for a program that never actually
+  # calls `.toStr()`/`.join()` on the outer list (per the "eager compile
+  # every method for every specialization" architecture noted elsewhere in
+  # this codebase's history).
+  fun toStr(self) -> Str =
+    return "[" + self.join(",") + "]"
 fun makeList(values: ...T) -> List[T] =
   l := List(head: None, tail: None, size: 0)
   for v := range values
@@ -503,3 +546,25 @@ test "list sort orders elements correctly"
 test "list join renders elements correctly with separator"
   l = makeList(1, 2, 3)
   expect l.join(",") == "1,2,3"
+test "list toStr formats a plain list and a nested list of lists"
+  l := makeList(1, 2, 3)
+  expect l.toStr() == "[1,2,3]"
+  chunks := l.chunk(2)
+  expect chunks.toStr() == "[[1,2],[3]]"
+test "chunk splits into sublists of at most size elements each"
+  l := makeList(1, 2, 3, 4, 5)
+  chunks := l.chunk(2)
+  expect chunks.length() == 3
+  expect chunks.get(0).unwrap().join(",") == "1,2"
+  expect chunks.get(1).unwrap().join(",") == "3,4"
+  expect chunks.get(2).unwrap().join(",") == "5"
+  expect l.chunk(0).length() == 0
+test "partition splits into elements matching a predicate, then the rest"
+  l := makeList(1, 2, 3, 4, 5, 6)
+  parts := l.partition(|v| v % 2 == 0)
+  expect parts.length() == 2
+  expect parts.get(0).unwrap().join(",") == "2,4,6"
+  expect parts.get(1).unwrap().join(",") == "1,3,5"