Discussion

[IvanBond]

Very good idea, Taylor! I like it. Thinking about upgrade of Tycho's collection by adding there same "all-in-one" code approach you use.

[Hugoberry]

I was pondering about about slightly different. How about introducing a folder structure and a build script that merges the tiny files same as @tycho into this massive script. The problem I faced was with tunning tests

[tycho]

Please refer to @tycho01 rather than @tycho.

[KiaraGrouwstra]

sorry about the mixup, other tycho! I like the project, feel free to incorporate anything from pquery if you like. Wish I'd figured out you could allow using periods in names this way at the time! I'm pretty sure I hadn't managed to include examples to visually present to the user at the time either...

[Hugoberry]

Meanwhile this happened https://github.com/Microsoft/DataConnectors/

[IvanBond]

Yeah, new era is coming. Looks promising, but will see how convenient it will be for PBI Desktop and Excel (my main interest at the moment).

[tnclark8012]

Happy to pull in or otherwise merge the repos

[Hugoberry]

I am "merging" the functions from both of the repos here https://github.com/Hugoberry/PowerQueryExtensions The repo has a different structure, and is meant to rely on Power Query SDK

[KiaraGrouwstra]

@Hugoberry: Great to see! Things have come a long way. :) Also love the PowerQueryFunctional library. Seems the upstream project (@KimBurgess's m-tools) added a couple more functions since, but seeing all of these usable with GUI descriptions is pretty glorious!

[KiaraGrouwstra]

I'm wondering if it would be possible to further integrate efforts to prevent the need for manually merging contributions across repos. pquery seems behind in its lack of documentation support, and if another library has superseded it, I wonder if I should put a note to that extent.

De-facto maintainer @IvanBond already commented here on that, but I'd wonder if these could reconciliated. Could repo structure differences (many vs. one file) be overcome? Is the main barrier in the DataConnectors-based repos the lack of a Load function?

On those functional repos mentioned above, I just wanted to mention that their Pipe function seems a godsend to address M's verbosity, if it could turn all the foo = f(bar, ...) into just f(...). That requires solving argument order too though, since M functions traditionally put the main argument first, prioritizing optional args over pointfree/composition. I did something similar for JS methods, so it's definitely possible.

To preserve optional args, I suppose a compromise to proper currying (also implemented in those M repos) would be to just transform (a, b, c?, d?) => ... into (b, c?, d?) => (a) => ... instead.

Not sure on preserving docs / type signatures. Docs aside, those optionals considerations are mirrored in JS -- same for type signature gymnastics, which have been a pain in TypeScript, though none if it essential I guess.

I wish DAX allowed function composition :), I'd take that over excel formulas' nesting and M's variable names any day...

[kimburgess]

Feel free to take lift anything of interest from m-tools. Primary use cases for that lib need it to built into that horrible record type so it stays portable within a *.pbix file and can be pushed to powerbi.com, but I recently split it all out into standalone functions so it can be assembled into the extensions for better desktop support. There's a pretty hacky bit of haskell in the root of the repo that assembles M.pq, if anyone's up to extending it / replacing it to also pump out everything in the extension form I'd love a PR.

P.S. @tycho01 for reordering arguments to internal functions so they are composable, take a look at PartialRight and PartialRight1. Or, for a batteries included approach that uses these with Pipe, see ChainOperations

[KiaraGrouwstra]

@KimBurgess: that's awesome, thanks! :)