source-academy / py-slang / 31136681664

86%

push

github

Stepper: give a built-in used as a value a hover popup (#409)

* Stepper: give a built-in used as a value a hover popup

is_function(print) had no way to show what `print` (unapplied) is:
a bare built-in-named Identifier rendered like any other name, with
no popup, unlike a user-defined function's mu-term hover.

The obvious "hack" -- checking whether an Identifier's name matches a
builtin -- already exists throughout reduce.ts/builtins.ts for actual
evaluation (contractCall's built-in dispatch), but that check can't
be baked into a real node type at translation time: a builtin's name
can be locally shadowed (e.g. `def print(x): return is_function(print)`
is valid, if confusing, Python -- see the extended discussion on
py-slang#404), and py-slang's substitution model only resolves that
shadowing as reduction proceeds, not statically up front.

Add ast.ts's markBuiltins: a display-only pass getSteps.ts runs on
each step's tree, after reduction, right before serialization. A
bare Identifier surviving to that point genuinely refers to the
built-in of that name -- any shadowing binding has already
substituted the occurrence away by then, the same guarantee
contractCall already relies on -- except inside a not-yet-invoked
function value's own body, which is opaque cargo substitution hasn't
reached yet, so the walk tracks bound names there exactly like
substitute() does, to avoid mislabelling a future recursive
self-reference as a builtin.

Since this walk runs after a contraction's preRedex/postRedex are
already captured by identity from the pre-relabeling tree, it also
returns a correspondence map so getSteps.ts can translate a marker's
redex into its (possibly relabeled) counterpart -- needed whenever
the redex itself is what gets relabeled, e.g. breakpoint()'s own
callee.

Renders via the new Builtin node type + syntaxProfile.ts's hoverText
rule, added to @sourceacademy/common-stepper/web-stepper in
source-academy/plugins#92 (not yet published, hence th... (continued)

4771 of 5978 branches covered (79.81%)

Branch coverage included in aggregate %.

50 of 50 new or added lines in 4 files covered. (100.0%)

10663 of 11944 relevant lines covered (89.27%)

165072.21 hits per line