Yesterday I had a discussion with someone speaking of the use of Combinators in Rust. That are the non consuming iterator methods like map(), filter(), enumerate, which I was knowing only as "iterator adapters". So what is the new, correct term?
Well... adapters allow one to combine things. For example a VGA to HDMI adapter allows you to combine a VGA monitor with a computer with HDMI video output. So "adapter" and "combinator" sounds like the same thing to me.
Except computer science people like to use the obscure "combinator" to make themselves sound more sophisticated
Thanks for your fast reply. Yes, now I understand both terms, and both make sense. But I would like to know what the new "official" Rust term is. Rust is already complex enough, I would prefer to use only one term in conversations.
Do you know if the consuming iterator methods like sum(), fold(), for_each() have a well accepted common name?
The closest thing to an “official” term would be something like “Iterator trait methods.” I suspect that both adapter and combinator will continue to see wide use because they have slightly different connotations, even when describing the same thing:
The term adapter implies that you have something with one shape but need to fit it into a hole of a different shape. For example, you may have an iterator of Option<T>s that you want to give to a function that wants an iterator of Ts instead.
The term combinator implies that you have two (or more) things that you want to merge into a single thing. For example, you might have a HashMap and an iterator of keys that you want to make into an iterator of (key, value) pairs.
The terms "adapter" and "combinator" derive from two separate computing traditions. The former is probably best known from the Gang of Four Adapter pattern, although strictly speaking the GoF Adapter adapts the interface while keeping the behavior, whereas iterator adapters do the opposite. [1]
The origins of the latter term are deep in the academia and go back to the 1920s and the work of Moses Schönfinkel and Haskell Curry on combinatory logic. [2] Alonzo Church's lambda calculus proved a more popular basis for a functional model of computation than combinatory logic, but via later work on functional programming, the term "combinator" is now familiar primarily from languages with roots in lambda calculus such as Haskell. It's basically synonymous with "higher-order function" these days.
"A callback-taking function" to be precise. The callback is (usually) a regular function, the function that accepts the callback is a higher-order function.
I think what I was getting at is that in many decades of programming in various languages for companies large and small in various countries I never heard of anyone using the term "higher order function". They were just functions that took as a parameter some other function to call back to. For example qsort() in C. Until I arrived at Rust and found all this new fangled language to get used to that was used to talk about the Rust language.
Seems to me that Rust has "first class functions". So functions are on an equal footing with any other data type. Given that, there is nothing higher order about higher order functions.
Quite, and that's what I alluded to by "separate traditions". The term "higher-order functions", like "combinator", comes from the functional paradigm, while "callback" is normal in imperative programming. [1] And for a long time there was little cross-pollination of ideas between the two communities. Given that Rust is a multi-paradigm language which derives a lot from the functional and academic side (moreso than most other "production" languages), and attracts programmers who are more or less familiar with FP, it's natural that some functional programming jargon also transfers from that side of the fence.
” Formally speaking, a function that takes a function as an argument or returns a function as a result is called a higher-order function. In practice, however, because the term curried already exists for returning functions as results, the term higher-order is often just used for taking functions as arguments.” Programming in Haskell by Graham Hutton
