I'm sorry that my explanation was so alienating to you. It was intended to be practical, but clearly I missed that mark for people without a certain amount of Haskell experience. Is there anything particularly confusing there that you would like explained?
The reason that I used the phrase "computational context" is because functors are very general. A Functor can be thought of as something that lets you translate functions with nothing special about them, just a function from a value to a value, into functions that operate correctly on non-vanilla values. Some examples of non-vanilla values (values with a computational context) are any value in a data structure (this is regular mapping over lists of values and trees of values), values that depend on external configuration or storing internal state (more useful for pure FP), operating on streaming data with functions that don't know about how you are streaming data, operating on data that might be missing without needing a null check, operating on data that might be actual data or an error code, operating on the results of a parser.
To give a python example, the lift function would be a decorator that made the function it was applied to correctly operate on almost any input value you gave it. If you give it a data structure, it is applied to all values in the data structure. If you give it a generator, it creates a new generator that runs the function over each element as it is generated, something like:
return (f(x) for x in argument_generator)
where f is the function that the decorator was applied to. This isn't as popular in Python, but .then() in promises/futures is a lifting function that lifts functions operating on data to functions operating on data that may asynchronously arrive in the future or fail to arrive at all.
This is very practical because it allows you to write code with very little repetition or boilerplate. When someone makes a data structure or processing technique (streaming, parsing, non-determinism), they write the code to operate on values inside of the data structure or process. This code is now only located in the definition of lift/map instead of being spread between every function that wants to work with that data structure, but not take advantage of anything special about the data structure. This removes boilerplates from functions and makes them easier to read and understand. In addition, this makes functions more extensible with less work. Anyone who comes along with a new data structure or processing technique can use all of the existing functions they have without having to write a new compatibility layer between the new data structure or processing technique and their old functions. Writing lifting functions separates particular data structure or processing techniques from general functions. A function can be lifted into many different contexts without any changes. This decouples specific implementations from general functions.
Ah, this is more interesting. I see what you're getting at; a lifting function is something like, in Python:
mapF = lambda f: functools.partial(map, f)
The thing is, in Python, there's a set of "magic methods" that any object of mine can implement (or which more commonly are implemented by generator objects), and Python's built-in iteration tools will then work on them. Using these is then as simple as:
def doAThing(x):
return foo(bar(xyz(x)))
a = MyIterableClass()
b = (doAThing(x) for x in a)
c = (doAnotherThing(self.bluh, x) for x in a)
doTheNextThing(c)
This pattern is reasonably common, popping up all over my code, and seems fairly reasonable to me. It's a bit more typing, but that's never been a bother for me.
When I need to implement a lifting function myself, it's pretty obvious that I do, and it's not something I think particularly deeply about.
I'm just not really sure where the novelty comes from, I suppose. Is this less common in other languages?
You are absolutely right that this isn't particularly novel. It generalizes a pretty wide range of concepts, which makes it hard to talk about accurately without resorting to jargon.
Iterators and generators are solutions to the same sort of problem but aren't quite as general. They do a good job of abstracting over streams and data structures, but I don't think they are as useful for dealing with single pieces of data with something special about them such as computations that could fail. It would be interesting to hack __iter__ to cover that case, but it's not idiomatic python. I think the "special types of data" idea works better in a statically-typed language so it would be non-pythonic on a couple of levels.
I use generators extensively in my python code, but I find they tend to infect programs. Once generators are used in one place, everything that interacts with that code works better as a generator. In Haskell, it is easier to use lifting for part of an expression without affecting the style of the rest of the program.
In addition, Haskell's type system and type inference make it possible to use these techniques in ways that would be very strange and difficult to do in Python which I didn't get in to in my original post because I wanted to stay in somewhat familiar territory. For example, functions are Functors and there are some interesting patterns that can be abstracted over by taking advantage of that. That said, if you thought of lifting like this as a strongly-typed slightly more general __iter__, you could be quite productive with it in Haskell. This is also useful for other languages because it makes it clear how much more general the __iter__ interface is and how it can be applied to things that are not data structures or streams.
The reason that I used the phrase "computational context" is because functors are very general. A Functor can be thought of as something that lets you translate functions with nothing special about them, just a function from a value to a value, into functions that operate correctly on non-vanilla values. Some examples of non-vanilla values (values with a computational context) are any value in a data structure (this is regular mapping over lists of values and trees of values), values that depend on external configuration or storing internal state (more useful for pure FP), operating on streaming data with functions that don't know about how you are streaming data, operating on data that might be missing without needing a null check, operating on data that might be actual data or an error code, operating on the results of a parser.
To give a python example, the lift function would be a decorator that made the function it was applied to correctly operate on almost any input value you gave it. If you give it a data structure, it is applied to all values in the data structure. If you give it a generator, it creates a new generator that runs the function over each element as it is generated, something like:
where f is the function that the decorator was applied to. This isn't as popular in Python, but .then() in promises/futures is a lifting function that lifts functions operating on data to functions operating on data that may asynchronously arrive in the future or fail to arrive at all.This is very practical because it allows you to write code with very little repetition or boilerplate. When someone makes a data structure or processing technique (streaming, parsing, non-determinism), they write the code to operate on values inside of the data structure or process. This code is now only located in the definition of lift/map instead of being spread between every function that wants to work with that data structure, but not take advantage of anything special about the data structure. This removes boilerplates from functions and makes them easier to read and understand. In addition, this makes functions more extensible with less work. Anyone who comes along with a new data structure or processing technique can use all of the existing functions they have without having to write a new compatibility layer between the new data structure or processing technique and their old functions. Writing lifting functions separates particular data structure or processing techniques from general functions. A function can be lifted into many different contexts without any changes. This decouples specific implementations from general functions.