rationalskepticism.org

mizvekov wrote:Yeah, but boost::lambda is pretty overkill for that, it's meant to provide lambda function support to c++98 compilers, and it is pretty hackish at that. No wonder it did not get accepted into c++11, and we got instead a proper lambda support which allows you to write their body just like any other function.
For partial function application, you could use boost::bind, which has been accepted into the standard as std::bind.
The syntax looks something like:

Code: Select all

        int b = 10;
        auto foo = [b](int a) -> int { return a + b; };
        auto bar = std::bind(foo, 1);
        std::cout << foo(2) << ' ' << bar() << std::endl;


This will print "12 11".

Oohh...this is new.

So here's the question: suppose b is a pointer to a dynamically allocated object, and this code appears in a function where the lambda foo is returned. How does the memory management work out? Are there useful smart pointers to deal with it?

By the way, do you have any recommended literature for Haskell beyond the beginner books?

I think the latter chapters in "School of Expression" are worth a read, especially the stuff on reactive programming. Other than that, there's Haskellwiki, which has articles on more advanced stuff like monad transformers and arrows. After that, I guess it's just research papers. When I was getting interested in Software Transactional Memory back in 2006, I was having to read Peyton-Jones' (very nicely-written) research papers.

I was using scheme actually, and perhaps only a subset of it.
At the time it felt pretty limiting, because it is hard to express state changes. I didn't learn anything about monads until much later.

Does it not have variable assignment and update and globals?

I've never used Scheme. Common Lisp on the other hand allows for the nastiest side-effects you can imagine. The components of any cons-cell can be mutated, so you can be handed a list, make a destructive modification on it, and find that you've radically altered data structures all over the place which happened to share parts of the original list. And this is before we getting into rebinding function symbols on the fly or making changes to the dispatch mechanism of functions.

Though I'm a little sceptical about using monads or any combinator language in an untyped language. The first serious combinator languages that I'm aware of came from ML, and one of the main guys in the ML community back then stressed that "tactic" combinators were only possible when you had a type system for higher-order functions. Often, when I'm working with monads and monad transformers, I'm not really thinking about code or thinking about what a function does. It's too abstract for me by that point. I get by just thinking entirely at the level of types. And I really don't want my frequent mistakes to show up as runtime exceptions. Given the heavy dosage of lambdas involved, I expect most of those exceptions to be thrown from closures a good distance away from the original error.