Hacker News Reader

Comment by amelius | Hacker News Reader

Here is a personal anecdote.

I recently tried to make a lambda function in C++ call itself. My first approach didn't work, because the variables were captured by reference, causing my program to crash (the enclosing scope had disappeared when my recursive lambda function was called). I easily tracked down that problem. But this generated a second problem: without using "capturing by reference", I couldn't make the lambda function refer to itself!

Of course, I looked around on the internet, and I found [1], which actually shows the insane amount of hacking required to make a lambda function call itself. And in the end, this solution didn't even work for me.

So, concluding, I think we're a long way from "functional programming in C++".

[1] http://cpptruths.blogspot.nl/2013/10/creating-recursive-lamb...

View on HN

Having a lambda call itself seems like self-serving functional wankery to me. Lambdas in C++ are nothing but unnamed classes with an () operator. They're blobs of captured values (or references), made immutable by default, that happen to have a function associated with them. If you want to recurse, give the damn thing a name, or rewrite the body in an iterative form.

unnamed classes with an () operator

They do have a name, but unfortunately it's just a compiler-generated one that's not known beforehand. And you would think that because the body of the lambda is really inside an operator(), 'this' could naturally be used to refer to the lambda itself, but alas, it doesn't work:

http://stackoverflow.com/questions/14531993/can-lambda-funct...

This is one thing about lambdas that I think the standards folks messed up. Having a lambda call itself might not be such a compelling use case, but it comes from the more general fact that a lambda cannot refer to itself, even though there isn't any reason preventing it from doing so; e.g. being able to pass itself ('this') as a parameter to some other function can be very useful.

You're asking for a persistent first class function; write it like one.

You can easily write a fixed-point combinator for this: https://gist.github.com/pervognsen/eca3bc833a65195f053c. The way you tie the knot in C++ type recursion is not that different from in other languages like Haskell. In Haskell you wrap it in a newtype (http://stackoverflow.com/a/5885270). In C++ you wrap it in a struct.

Why does a rather trivial construct like this require an arcane label like 'fixed-point combinator'?

In any case, this is cheating. What you effectively have here is a pair of mutually recursive functions, Recursive<>::op() calls anonymous_lambda_type::op(), which calls Recursive<>::op() again, and so on. I checked Wikipedia without even knowing 'mutual recursion' was an official mathy thing, it just sounded right, and I'm pretty sure this label is sufficient to describe the idea.

If only even more advanced functional concepts were demonstrated without all the unnecessary pomp and ceremony common to Haskell and other functional advocates then I'm sure we'd all benefit. I'm constantly reminded when I see examples like this of Bodil Stokkes presentation 'What Every Hipster Should Know About Functional Programming'

http://vimeo.com/68331937

> Why does a rather trivial construct like this require an arcane label like 'fixed-point combinator'?

Because that's what it is. I'm trying to communicate to people who know basic ideas from computer science. This is the last place I would expect someone to call the Y combinator too highbrow.

> In any case, this is cheating.

You're not making any sense.

> Why does a rather trivial construct like this require an arcane label like 'fixed-point combinator'?

On a site named after fixed-point recursion, no less.

It's not the idea, but the jargon that's offensive.

I get this with higher-kinded types. The concept seems pretty straightforward to me, but go and read any explanation of it and it seems like someone got a bulk discount on asterisks.

Yeah. It's not actually complicated, but I don't know if you could express it more simply. The "kind" of a type of an actual piece of data is represented with an asterisk. Higher kinded types, then, are thought of as (curried) functions from types to types.

So we have:

    Integer :: *
    String :: *

    Set :: * -> *
    Set Integer :: *

    Map :: * -> * -> *
    Map Integer :: * -> *
    Map Integer String :: *

You can say things like "a type function that takes 3 arguments", but that makes it harder to express things like

    StateT :: * -> (* -> *) -> * -> *

Higher kinded types can be thought of as curried functions from types to types, but that's not how i think of them, and that's exactly the kind of explanation that i find unnecessarily offputting. For some people, thinking about functions on types is natural and useful, but for people not already deep in the functional juju, it's not.

My explanation is something like:

"You know generic types, right? They have a type parameter, and when you bind that type parameter to a particular concrete type, you get a concrete type. So, List<E> is generic, and when you bind it to the concrete type String, you get a concrete type List<String>. Well, a higher-kinded type is a generic type where you can bind the type parameter to a generic type instead of a concrete type. So you might have CollectionMaker<T>, and bind that to List<E>, and end up with a CollectionMaker<List<E>>, where the E isn't bound. Then, particular methods on the class can go on and bind that parameter to particular types."

That explanation is probably isomorphic to the one about functions on types. But it's given in terms of constructs a programmer might actually use.

I'm in favor of getting a variety of approaches to explanation out there. My post was attempting to provide context you'd seemed to be missing, not attempting an entirely separate explanation. I'm sorry you found it offputting. Using C++ template style syntax for paramaterized types does seem a reasonable alternative, though they're not exactly known for their clarity. I do think you're going to lose a whole lot of programmers with CollectionMaker (smelling a bit of industrial-Java style overengineering) - a better example should be found.

"But it's given in terms of constructs a programmer might actually use."

A lot of programmers I know actually use StateT - myself included.

> This is the last place where I would expect anyone to call the Y combinator too highbrow

It's not highbrow at all, that's what annoys me. I can describe in detail how code like this will translate to machine code, the operations on the stack, the flow control going on etc and think of several ways such constructs could be used to solve real problems. I can, however, read the entire Wikipedia page on 'Fixed-point combinators' and learn nothing beyond the first paragraph which describes their broad classification and properties.

Don't you consider it a had sign that the Wiki page for FPCs eventually reads "The analog for mutual recursion is a polyvariadic fix-point combinator, which may be denoted Y*." ... and when you Google 'polyvariadic' the first page of hits is almost entirely Haskell? ... oh and only ~5,000 results. Basic terminology indeed, clearly not niche gouging wankery.

In any case, neat solution to recursing in to a C++ lambda. I'm just venting generally.

It goes back to the mathematical roots of programming. Turns out that if your language consisted entirely of unnamed lambda functions, it would still be turing-complete because you could use one of several types of combinators to implement everything else. The Y combinator and a few other similar ones implement recursion, which is quite a feat for such a limited language.

Mathematical terminology exists only to add precision to human languages, which are notoriously vague. It can be overdone, of course. Polyvariadic is a bit silly, it just means that the combinator has been generalized so that it works on functions which have more than one argument (literally "many-variable-having"); the original Lambda Calculus pared away even that to leave just functions of one argument.

That hypothetical language, btw, is called the Lambda Calculus. It was formalized and studied by Alonzo Church, and entered software engineering most directly in the form of Lisp. Most of the research these days probably happens in Haskell and similar languages.

Is there any difference between "variadic" and "polyvariadic"? The two seem to both mean "taking a variable number of arguments", but definitions of each never seem to mention the other. "Variadic" is standard C terminology...

It has a label like that because the math folks who came up with it a hundred or so years ago were thinking of math, not trying to accommodate math-phobic C hackers in the next century.

How the hell is "pair of mutually recursive functions" any less "arcane" than "fixed-point combinator"? "fixed-point combinator" is an obvious name that describes exactly what it does: it's a combinator that returns a fixed point. Can't get plainer than that.

To someone who knows what a function is, and what mutual recursion is, but does not know what a fixed-point is or what a combinator is, certainly the former is more understandable and the latter sounds more like jargon. That's a pretty specific position in knowledge-space to be targeting, but it seems likely the one the parent occupies.

A more important point is that "fixed-point combinator" tells you what the function does - it takes a function (a combinator is a function that operates on a function) and returns its fixed point; a "pair of mutually recursive functions" could do anything, and so conveys less information.

>"which actually shows the insane amount of hacking required to make a lambda function call itself"

I doesn't require any hack at all, it doesn't even require to capture the variable. You just need to be sure to make it persist and be accessible in the scope of the lambda.

For example:

http://ideone.com/6hwVGy

That said, please don't do it in production code. std::function is very inefficient when it is being used in a recursive way

Why is it inefficient with recursion? I know that at least non-recursive usage of std::function is generally well-optimized by most compilers.

When you wrap a lambda into a std::function variable, it involves a call to a virtual function which add overheads (often unnoticed unless you repeat the call several times), so a regular recursive functor would be even faster.

The subject was discussed in the following threads:

http://stackoverflow.com/questions/2067988/recursive-lambda-...

http://stackoverflow.com/questions/17066667/overhead-of-recu...

The lambda function was an event handler, that needed to add itself to the event loop under certain conditions (retry).

Its parent scope is not persistent.

The article talks mostly about purity, and that is easily achieved.

I don't know about that link, but in general you would use a fix point combinator. The Fit library has a fix point combinator here:

http://pfultz2.github.io/Fit/doc/html/fix/

So you could implement a generic factorial like this:

    auto factorial = fit::fix([](auto self, auto x) -> decltype(x) 
    { 
        return x == 0 ? 1 : x * self(x-1); 
    });

You can in fact define a fixed point combinator in good old C99, one that compiles without warning, and doesn't take all that much code.

From http://www.ioccc.org/2014/whowon.html

   Most functional
   Freek Wiedijk - Y combinator

We'll have to patiently await publication of the source though...

Do you have any code examples?

The Y combinator causes problems with typing (it has an infinite recursive type), so I'm curious what solution they came up with.

In any case, if calling a lambda function from within itself is going to take more than a single line of straightforward code, then I'm afraid the solution still doesn't cut it for practical purposes.

They could've done something similar to what you do when you implement a functional language in C and used a union to represent every possible return type, and included functions (closures if you will) in that union, then you solve the problem of the infinite type.

why does this matter, what is the overwhelming use case for self referential anonymous functions.

so I'm curious what solution they came up with.

I'm guessing a cast. The infinitely long type is not at all a problem in languages with weak type systems like C.

Reply on news.ycombinator.com