Pure Lsp Go

Execute Pure code via the LSP bridge's go()

Requires a running bridge (pure-lsp health) — and never curl it, pure-lsp is the only reliable client. See references/lsp-devloop-usage-rules.md for both, plus the welcome.pure and database-setup conventions this skill assumes.

The mental model

There's exactly one designated entry point: a function literally named go, with signature go():Any[*] (or go():String[*] / go():String[1]). It's not "call any function with arguments" — it's "run this one zero-argument function." To exercise your actual function with specific inputs, write go() as a thin wrapper around it:

function myCustomFunction(x:Integer[1], y:Integer[1]):Integer[1]
{
  $x + $y;
}

function go():Any[*]
{
  print('result = ' + myCustomFunction(19, 23)->toString(), 1);
}

Steps

Use the repo-root welcome.pure ($LEGEND_ENGINE_ROOT/welcome.pure) as the go() host — a git-ignored REPL file that already defines function go():Any[*]. Do not create a fresh /tmp/<name>.pure per run: it collides with orphan overlays, and a file outside a registered repo is silently ignored (No go() function found in compiled sources). Full reasoning: references/lsp-devloop-usage-rules.md.

1. Edit welcome.pure's go() body with what you want to run (add any missing import; comment out pre-existing scaffolding lines that fail locally, e.g. the getTestConnection(DatabaseType.Snowflake) line).

2. Execute it, passing the file so it is (re)compiled atomically before go() runs:

   pure-lsp go $LEGEND_ENGINE_ROOT/welcome.pure

   Returns {"success": bool, "error": str|null, "output": str} plus return-value fields. output is whatever go() printed via print(...); its return value arrives separately in returnValue, with returnKind / returnType / returnSize / returnTruncated alongside it.

   So go() does not need to print a primitive result to make it visible — returning it is enough. Only a complex return (a Class instance, Relation or lambda) still needs print(): those report their type and size with a null value rather than having their object graph walked. See the pure-lsp-execute skill for the full field table.

To unload a pushed file (an orphan go() overlay, say): POST /delete {"uri": ...} — deleting it on disk does not clear the overlay. See the conventions reference.

Multi-file: compile several files, then execute, in one call

When go() and the function(s) it calls live in separate files (or you're validating several related changes at once), pass the files straight to go instead of check-ing each one first:

pure-lsp go Main.pure Helper.pure OtherHelper.pure

One atomic compile of the whole batch, then go() — argument order is irrelevant, and a single broken file rolls the whole thing back (success: false, errorUri naming the real culprit) so go() never runs against a partial model. Always pass every edited file in one call rather than checking them one at a time; that's rule 2 in references/lsp-devloop-usage-rules.md.

Things worth knowing

• go recompiles the entire session, not just the file you just checked. If some unrelated file already loaded into this session has a compile error, go() will fail even though your new snippet is perfectly fine — read the error's source file/location before assuming your code is broken.
• go runs on the interpreted engine. By default that means no plan generation — a plain execute() runs fully interpreted (see "Execution routing" below for how to change that). A successful interpreted go() is a fast dev-loop signal, not proof the compiled engine (or PCT) will agree — but with a backend Server wired in you can make it exercise the real plan-gen + execute path.
• On failure, output/error includes whatever was printed before the crash plus either a Pure stack trace (for a Pure-level exception) or a raw Java stack trace (for anything else) — read the whole message, the useful part isn't always at the top.