[Power Query] function curry with up to N levels and maintaining function signature types

100%

[Power Query] function curry with up to N levels and maintaining function signature types

✓ Published0🌍 Public

Last edited Mar 23, 2018

Created on Mar 23, 2018

This example demonstrates a Power Query function named `Function.CurryN` that enables currying of any function with up to N argument levels while preserving the original function's type signature. It shows how the function dynamically inspects the input function's parameter metadata via `Type.FunctionParameters` and `Type.FunctionRequiredParameters` to determine arity, then recursively builds and invokes intermediate closures using `Function.From` and `Function.Invoke`. The test file `test.pq` applies this to `Text.Contains`, first without a specified N (currying all three parameters), then with explicit N values of 2 and 1, illustrating flexible partial application. The implementation relies on Power Query's standard library functions like `Record.SelectFields` and `Type.ForFunction` to manage type safety across each curry level.

AI-generated description

Similar vizzes

Loading thumbnail…

[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.

HHugoberry

62% match

Loading thumbnail…

[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.

HHugoberry

61% match

Loading thumbnail…

[Power Query] Closures, partial application and cascading parameters

This example demonstrates a data-visualization technique that uses Power Query’s `setParameters` function to create cascading parameters through closures and partial application. The code shows how a function `_fn_` is wrapped in a closure, where `fnCopy` is defined as `(x) => setParameters(fn(x),{1..x})`, allowing dynamic parameter injection. The outer call `setParameters(fnCopy,{1..9})` further restricts the parameter set, illustrating nested parameter scoping. The visualization itself is not a chart but a programmatic pattern for controlling function behavior, relying on Power Query’s M language rather than a graphical library. It highlights how parameter cascading can be achieved without external data sources or rendering, focusing on functional composition.

HHugoberry

60% match

Loading thumbnail…

[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.

HHugoberry

60% match

Loading thumbnail…

[Power Query] [m] Closures

This example visualizes the inner workings of a TypeScript-based function-closure mechanism, showing how parameter lists are programmatically overwritten and restricted. It demonstrates the step-by-step process of copying a function (`fnCopy`) and applying `setParameters` to limit its arguments to a specific range, then wrapping that operation with another `setParameters` call to further constrain the allowed parameter indices to 1–9. The code uses TypeScript’s type system and higher-order functions (like `setParameters`) to manipulate closures at runtime. The rendering approach is textual, highlighting the sequential logic through code snippets, with no graphical or data-driven output beyond the functional transformation.

HHugoberry

60% match

Loading thumbnail…

[Power Query] Decorate a function parameter with allowed values {1..9}

This example demonstrates a custom Power Query function parameter decorator that restricts input values to the range 1 through 9. It shows how a function like `fnCopy` can be wrapped with `setParameters(fn, {1..9})` to enforce allowed numeric values, improving type safety and self-documentation. The code relies on Power Query’s native function-handling APIs, specifically `setParameters`, which validates and assigns metadata to the parameter. The visualization likely displays the decorated function’s behavior in a query editor, with the allowed range visible as part of the parameter definition. No external rendering libraries are used; the example focuses on the query logic itself, not on graphical output.

HHugoberry

59% match

Loading thumbnail…

[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.

HHugoberry

59% match

Loading thumbnail…

Power Query attempt at decompiling a function call

This example shows a Power Query (M) custom function that decompiles a `List.Skip` call into its component parts—the list, the offset, and an optional count. It demonstrates how M’s standard library functions `List.Skip` and `List.FirstN` are composed to recreate the logic of a function call, with `skippedInput` holding the intermediate result after skipping a given number of elements. The code reveals the underlying structure of the operation by explicitly handling a null count fallback, which would otherwise be implicit in the original function. This visualization highlights the metaprogramming aspect of Power Query, where code itself is treated as data for inspection.

HHugoberry

58% match