search_replace function about zed HOT 2 OPEN

Building further off what was shown previously, in the absence of the proposed purpose-built search_replace function written in Go as a core part of the Zed language, it could be written as a user-defined function such as this search-replace-func.zed.

func search_replace (s, change_map, default): (
  coalesce((over change_map with s | switch (case regexp(key, s) != null => yield value | head 1)), default)
)

I've also broken out the map of pairs for search/replace in this changes.zed.

const changes = |{
  "foo|bar": "The Foobar category",
  "a.*\\-z.*": "The A-to-Z category"
}|

Putting it all together at the command line:

$ zq -I search-replace-func.zed -I changes.zed 'category := search_replace(desc, changes, "The default category")' descriptions.zson 
{desc:"It's foo time",category:"The Foobar category"}
{desc:"a is the first letter-z is last",category:"The A-to-Z category"}
{desc:"Something else",category:"The default category"}

This shows simple modularity at the CLI. We've also discussed the idea of more formally introducing "Zed modules" (#2599) and related concepts like having a standard library of functionality written as Zed to augment the rest of the core functionality implemented in Go, community users being able to share their own modules/libraries easily such as via GitHub, and so forth. This opens the door to being able to deliver enhancements in the short term as Zed that might be hacky at times but can be used like a black box. If perf problems or functional gaps in such an implementation limit usability, usage in its initial form would help validate the use cases for more ambitious core functionality later written in Go.

from zed.

Also related: The original user later expressed an interest in being able to pull the search/replace pairings from a pool rather than defining them in a const. I was able to hack something together that does this using existing building blocks, but it's super ugly. A better approach would be if we had what's described in #3201.

Separately, @mattnibs has looked over everything shown here and had the impression that a "cross-product join" would be the way he'd approach this problem.

from zed.