The Map Library

Recently I’ve written about Wilfred Hughes’ ht library for dealing with hash tables and Nic Ferrier’s kv library for dealing with alists and plists. Nicolas Petton commented that there is also the map library, which is built into Emacs as of version 25.2.

What makes Petton’s map library unique is that the functions will operate on alists, hash tables, or arrays so you don’t need to worry about separate functions for each data type. The functions do the expected things such as getting and putting values, mapping over key/value pairs, filtering, and so on.

Unfortunately, there doesn’t appear to be any documentation but it’s easy to look at the source to see what functions are available. The DOC strings do a good job of explaining what each function does.

If you have code that uses two or more of the supported data types, you should consider the map library. It provides a consistent set of functions that operate on them all. In particular, it makes it easy to change the data type of a variable because most of the code to manipulate it will be the same. As with the ht and kv libraries, the names of the functions and the ordering of the arguments are consistent and intuitive. That makes it easy to remember them.

This entry was posted in General and tagged . Bookmark the permalink.
  • NoonianAtall

    map.el is very nice, but I really wish that it supported plists as well. Alists and plists are both common, but there's no common API to work with them, so if you want to make a library that supports both, you have to hack it yourself.

    • Phil

      ...or even better, improve submit improvements to map.el.

      • NoonianAtall

        I thought about it, and I might. However, I have my own projects right now, and Nicolas is planning to work on it himself. Please allow me to make a suggestion without implying that I must fix it myself.

        • Phil

          No offense intended. I was merely pointing out that improving a deficiency in code that is already in Emacs is better for the community than writing completely new code that isn't part of Emacs. I wasn't suggesting that it's your responsibility to do so, though. Making sure that you'd contemplated the option was all I was trying to achieve.