Partially-applied afterChar in splitOnComma hangs the compiler indefinitely

[ilyakooo0]

Problem

Routing the tail recursion of splitOnComma through a partially-applied afterChar causes the Knot compiler to hang indefinitely — it never finishes compiling, with no error or progress.

Minimal reproduction

-- Works — compiles in ~1s
afterComma : Text -> Text
afterComma = \\s -> if s == ""
then ""
else if take 1 s == ","
then drop 1 s
else afterComma (drop 1 s)

splitOnComma : Text -> [Text]
splitOnComma = \\s -> if s == ""
then ([] : [Text])
else union [trim (beforeComma s)] (splitOnComma (afterComma s))

-- Hangs — never finishes compiling
afterChar : Text -> Text -> Text
afterChar = \\sep s -> if s == "" || take 1 s == sep
then ""
else afterChar sep (drop 1 s)

splitOnComma : Text -> [Text]
splitOnComma = \\s -> if s == ""
then ([] : [Text])
else union [trim (beforeComma s)] (splitOnComma (afterChar "," s))

The only difference is that afterComma (single-argument, bespoke) is replaced by afterChar "," (partially-applied, generic). The recursion structure is identical.

Impact

This prevents factoring the beforeX/afterX family of string helpers (used throughout Skrepka's server.knot) into a single generic beforeChar/afterChar pair, forcing code duplication.

Environment

Confirmed 2026-07-11 against the current Knot compiler. A 9-line repro of splitOnComma = ... splitOnComma (afterChar "," s) never finishes compiling, while the bespoke single-argument afterComma compiles in ~1 second.

Reference

• Skrepka server.knot line ~601-606: the comment documenting this bug and the decision to keep bespoke per-separator helpers