Skip to content

lowering: a partially applied lambda closes over its argument - #52

Merged
simontreanor merged 2 commits into
mainfrom
fix/section-partial-application
Jul 31, 2026
Merged

lowering: a partially applied lambda closes over its argument#52
simontreanor merged 2 commits into
mainfrom
fix/section-partial-application

Conversation

@simontreanor

Copy link
Copy Markdown
Owner

From the report: List.map ((+) 2) emitted functools.partial(lambda a, b: a + b, 2) where the longhand fun y -> y + 2 emitted lambda y: y + 2. Operator sections lower to lambdas, so the idiomatic spelling produced worse Python than the form it replaces — backwards for a language whose output is meant to be a first-class artifact.

A partial application of a lambda now substitutes instead of wrapping:

def a(x, xs):                                   def a(x, xs):
    return len(_pf_filter(                          return len(_pf_filter(
        functools.partial(                              lambda b: x == b, xs))
            lambda a, b: a == b, x), xs))
def c(xs):                                      def c(xs):
    return _pf_map(functools.partial(               return _pf_map(lambda b: 2 + b, xs)
        lambda a, b: a + b, 2), xs)

One fewer call layer, the functools import is no longer pulled in for this reason alone, and the per-call indirection goes away.

The two guards are the part worth reviewing, since both protect something the wrapper gave for free:

  1. A non-atomic argument keeps the wrapper. functools.partial evaluates its arguments once, now; a lambda body evaluates them on every call. ((+) (effect 1)) must not start calling effect per element, so only names and literals move inside.
  2. An argument whose name is also a remaining parameter keeps the wrapper. ((+) b) must not fold into lambda b: b + b. The conservative choice is the wrapper rather than renaming, so the emitted parameter names stay the ones the reader expects.

Both have tests, and both still produce correct answers at runtime (verified: the shadowing case gives [11, 12], not [20, 20]).

The substitution walks the Python IR and respects shadowing, so a nested lambda rebinding the name is left alone. It applies to any partially applied lambda, not only sections, so a user's own (fun a b -> …) 2 gets the same treatment.

Tests: the existing operator_section_lowers_to_a_curried_lambda pinned the old behaviour exactly and is updated; four new cases cover the reported shape in argument position, the bare operator staying a binary lambda, and each guard.

Full suite, clippy, fmt and the 23 doc lessons clean.

Reported from the other repo: `List.map ((+) 2)` emitted
`functools.partial(lambda a, b: a + b, 2)` where the longhand `fun y -> y +
2` emitted `lambda y: y + 2`. Operator sections lower to lambdas, so the
idiomatic spelling produced worse Python than the form it replaces, which
is backwards for a language whose output is meant to be a first-class
artifact.

A partial application of a lambda now substitutes instead of wrapping:
`lambda b: 2 + b`, and `lambda b: x == b` for `((==) x)`. One fewer call
layer, no functools import pulled in for this reason alone, and the
per-call indirection goes away.

The wrapper stays wherever folding would change meaning, which is the part
worth reviewing. An argument that is not a name or a literal keeps it,
because functools.partial evaluates its arguments once and now while a
lambda body evaluates them on every call — `((+) (effect 1))` must not
start calling `effect` per element. An argument whose name is also one of
the remaining parameters keeps it, because substituting would capture:
`((+) b)` must not fold into `lambda b: b + b`. Both have tests, and both
still produce the right answers.

The substitution walks the Python IR and respects shadowing, so a nested
lambda rebinding the name is left alone. This applies to any partially
applied lambda, not only sections, so a user's own `(fun a b -> …) 2` gets
the same treatment.
@simontreanor
simontreanor merged commit 15e62ca into main Jul 31, 2026
11 checks passed
@simontreanor
simontreanor deleted the fix/section-partial-application branch July 31, 2026 18:27
@simontreanor simontreanor mentioned this pull request Jul 31, 2026
simontreanor added a commit that referenced this pull request Jul 31, 2026
Two dogfooding reports from real programs, and the standard-library sweep
they triggered.

Language:

* a `type` declaration can name an imported type, bare or module-qualified
  (#36) — the one gap that changed a program's architecture rather than its
  phrasing, forcing two modules into one file
* field access resolves from the base's type when it is known, so two
  records may share a field name without prefixes (#37)
* parameters destructure: tuples (#38), records (#40), and `_`
* a direct self tail call lowers to a loop, so an interactive turn loop no
  longer walks the stack (#39, #41)

Standard library — about 115 new members, taking every module to the F#
core set: List (#42), Seq (#44), Set and Map (#46), String (#47), Option
and Result (#48), then a member-by-member FSharp.Core audit (#51). Every
built-in member now carries a one-line description and its complexity in
hover and completion (#43, #49), enforced by tests.

Fixes:

* `pyfun run` on a single file gives the program its own stdin, so an
  interactive program is runnable by the command whose job is running
  programs (#35)
* a partially applied lambda closes over its argument instead of being
  wrapped, so `List.map ((+) 2)` emits `lambda b: 2 + b` (#52)
* every multi-argument callback's scheme put the effect variable on the
  wrong arrows, so `List.fold` could never accept an effectful folder (#51)
* `Seq.empty` lowered to a bare `iter()`, a TypeError (#51)

One source-incompatible change, which is why this is 0.4.0 and not 0.3.1:
a dotted `extern` target whose module prefix cannot be decided from the
text is now a compile error naming the `extern import` to add (#50).
`sys.stdout.flush` used to emit `import sys.stdout` and fail at runtime;
declaring `extern import sys` fixes it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant