Power Query attempt at decompiling a function call

[PowerQuery] Decompiling List.Range function

This example shows how to decompile the Power Query `List.Range` function into its underlying expression tree, revealing the nested structure of arguments and function bodies. It uses the `Value.ResourceExpression` API to access the function’s AST, then recursively traces and serializes the structure via `Json.FromValue`, with helper logic that converts values, types, lists, and records into a JSON-compatible format. A second expression, `DeepDecompile.pq`, directly navigates the resource expression’s `[Expression][Arguments]{0}[Function][Expression][Expression]` path to extract the innermost function body. The visualization renders the resulting JSON as a plain-text trace, highlighting the difference between high-level metadata lookup and low-level AST traversal.

67% match

[Power Query] Experimenting with thunks and trampolines

This example demonstrates a manual implementation of tail-call optimization using thunks and a trampoline, written entirely in Power Query. It shows how recursive functions can be restructured to avoid stack overflow by wrapping each recursive call in a thunk—a zero-argument function—and then driving the computation forward with a trampoline that repeatedly invokes the current thunk until a non-function value is produced. The code defines two custom functions: `make_thunk.pq`, which uses `Function.Invoke` to delay a function call, and `trampoline.pq`, which uses `List.Generate` with type checking via `Type.Is` and `Value.Type` to iterate until the result is no longer a function. The example highlights a purely functional, dataflow-driven approach to control flow, with no external libraries or visual rendering, relying solely on Power Query’s standard library.

64% match

PowerQuery list functions cheat sheet

This example is a cheat sheet for Power Query's list functions, organized as a reference card with sections for addition, averages, generators, information, membership, numerics, ordering, and selection. It shows concise code snippets with sample outputs, such as List.Sum({1, 2, 3}) ⇒ 6 and List.Generate(() => 10, each _ > 0, each _ - 1) ⇒ {10, 9, 8, 7, 6, 5, 4, 3, 2, 1}. The source is a gist by Hugoberry.

64% match

[Power Query] Closures, partial application and cascading parameters

This example shows how Power Query’s cascading parameters control a dynamic data-filtering workflow. The code defines a closure that partially applies a filter function, returning a new function for later invocation. Using the M language’s `Function.Invoke` and `List.Select` APIs, it passes a column value into a nested lambda, demonstrating how parameter values flow through successive scopes. The gist’s `fn.ts` file illustrates the pattern with a simple identity function, while the visible M code applies this pattern to filter table rows based on a stored parameter. The approach highlights how Power Query’s functional composition enables reusable, parameter-driven query logic without hard-coding values.

Power Query navigate the documentation of #shared functions. [M code]

This example visualizes the complete set of functions exposed by Power Query’s `#shared` namespace, organized into a navigable table. It shows each function’s name, module, category, example code, description, and signature. The M code uses `Record.ToTable` and `Table.SelectRow` to filter functions, then leverages `Value.Metadata` to extract documentation fields like `Documentation.Category` and `Documentation.Examples`. It also parses module names via `Text.Split` and builds signatures dynamically. The result is a self-documenting inventory, enabling users to browse and understand the entire Power Query function library directly from the environment.

[Power Query] Closures, partial application and cascading parameters

This example shows how Power Query applies functional techniques to build a cascading parameter system, where a selection in one step narrows the choices in the next. It demonstrates closures and partial application by defining a function `fn.ts` that takes an initial parameter `x` and returns a second function awaiting `y`, ultimately computing their product. The visualization uses this pattern to drive linked dropdowns or sliders, where the output of one control feeds directly into the next. The code relies on Power Query’s native M language functions for data shaping, with no external libraries, and the rendering approach is not specified in the provided snippet.

[Power Query] Closures, partial application and cascading parameters

This example demonstrates how Power Query’s M language implements closures and partial application through nested functions. The code defines `addTo` as a function that returns another function, capturing the outer variable `x`. By calling `addTo(5)`, it creates `addToFive`, a closure that retains the value 5 in its scope. When `addToFive(3)` is invoked, the closure evaluates to 8, showing how cascading parameters flow through each layer. The rendering is purely textual, with no external libraries or data sources; the logic itself is the visualization.

Gist a25bf43fbc2ada9a1cc29f874f509134

This example shows a Power Query custom function that extracts list items by their numeric positions, returning a new list with only the selected elements. The function `List.SelectPositions` takes a source list and a list of indices, with an optional parameter to shift the starting index from zero-based to one-based numbering. It uses `List.Transform` with a buffer for performance, applying `_{_ + StartPosition}?` to safely handle out-of-range positions by returning null. The implementation relies on the standard Power Query `List` and `Value` APIs, including `Value.ReplaceType` and `Value.ReplaceMetadata` to attach documentation and usage examples.