Generating nested data drill-down code based upon the current Portal selection

[Lambeaux]

Now that Portal works with VSCode (and soon IntelliJ/Cursive), it may be time to explore some code generation features.

This is a new feature idea for Portal and I wanted to start crowdsourcing some thought on the matter. How would the community feel about adding a "Where am I?" feature to complement dereferencing the Portal atom. It would output the actual code that, when evaluated, outputs the data you have currently selected with respect to Portal's root of the data.

In the simplest case, it is generating code that "drills down" for you, in order to fetch a nested value. But it could evolve to do more.

Some initial thoughts:

• The code being generated is meant for "drilling down" or "navigating" into nested data structures.
• It's okay if there's minimal utility when dealing with data that's more flat than nested.
• Reasonable default might be to drill with respect to Portal's root.
• Alternative is to specify pre-drill code that executes prior to generating the drill code so you need not always start from root.
• It should be possible to add alternative flavors of the generated code across collections, maps, reduces, etc. based on what the user is trying to do.
• Could borrow some ideas from generative testing to ensure accuracy of generated code relative to the data loaded in Portal.

Some things that would help:

• Has this been done before (links to projects or papers appreciated - I'm kind of stuck in the "I don't know what I don't know" loop when trying to search for this specifically)?
• Alternative ideas for identifying the boundary points for drilling operations; more specifically, how to select a starting point beyond the Portal atom root.
• Any other ideas regarding this capability or code generation problems in general.

Some early implementation notes describing potential approaches:

• Establish a mapping of type → function, for reasonably appropriate functions, that drill deeper into that type.

[coyotesqrl]

A simple/dumb solution is to expand the shape of the atom to include the equivalent of a breadcrumb trail from root to the current value. On each step in/out that trail would be appended/truncated as appropriate.

[Cyrik]

"type → function" map sounds like a good start, although it would be great if the dispatch was a little more "general"? since most of us are dealing with maps its a little restrictive to have only one function for that.

I'm not exactly sure what a second dispatch parameter could be, but maybe a metadata key on the var?

as for prior art: there's specter which isn't very idiomatic but pretty powerful, pretty similar to haskell lenses. then theres the concept of using a regex like structor to describe the selection, something like seqexp