Overview

diff.update allows a user to see inline code diffing within UCM before updating the codebase. This is most helpful for reviewing changes locally.

A simple example (without color; deletions would be in red and additions in green):

scratch/foo1> diff.update diff.update

  Preview of changes that would be made by `update`:

  New definitions:
    + bar : Nat
    + bar =
    +   use Nat +
    +   foo + 1

  Updated definitions:
      foo : Nat
      foo =
        use Nat +
        x = 1
    -   y = 3
    +   y = 4
        x + y

  + (added), - (deleted)

  Run `update` to apply these changes.

scratch/foo1> view foo

  foo : Nat
  foo =
    use Nat +
    x = 1
    y = 3
    x + y

Implementation approach and notes

The implementation reuses existing update infrastructure by leveraging getNamespaceDependentsOf and hydrateRefs
from Cli.UpdateUtils to fetch old definitions from the codebase. It employs an inline diff algorithm using
Data.Algorithm.Diff to compute line-by-line differences between old and new definitions—including terms, structural
types, and abilities. The pretty-print environment includes names from the typechecked file (via UF.typecheckedToNames)
that shadow namespace names, ensuring new references resolve to names rather than hash abbreviations. Following the
existing HandleInput/*.hs pattern, the implementation uses a dedicated DiffUpdate.hs module and exposes the
functionality as a diff-update tool in the MCP server for AI agent access.

Interesting/controversial decisions

The implementation chose an inline diff format over side-by-side comparison, using the -/+ prefix format (like git diff) rather than a side-by-side layout, as this approach is more compact and familiar to developers.

Test coverage

• Have you included tests (which could be a transcript) for this change, or is it somehow covered by existing tests?

• Would you recommend improving the test coverage (either as part of this PR or as a separate issue) or do you think it’s adequate?

  • Not particularly, though maybe we could go with larger diff examples?

Final checklist

• Choose your PR title well: Your pull request title is what's used to create release notes, so please make it descriptive of the change itself, which may be different from the initial motivation to make the change.
• Update your PR description if the specifics of the PR have changed over time.
• Include transcripts or screenshots that demonstrate the changed behavior.
• If you changed .cabal files, make sure the package.yaml files are up-to-date instead.