Y-Combinator | Playing around with different Y Combinator | Functional Programming library

The first string prints out the following error:

The lambda calculus only works with normal order reduction (i.e. arguments are only evaluated when their values are needed), and Scheme uses applicative order reduction (arguments are evaluated first), except in "special forms".

Your code works with regular numbers not because of the numbers, but because of cond, which will evaluate at most one of its clauses.

If you replace the cond in your sum1 with a regular function, your computation will not terminate with regular numbers either.

The only way I see is make evaluate() a template method; if you want to be sure to receive a Functor (but you can simply accept a callable: see Yakk's answer):

Undefined behavior is a non-localized phenomenon. If your program encounters UB, that means the program's behavior in its entirety is undefined, not merely that little part of it that did the bad thing.

As such, it is possible for UB to "time travel", affecting code that theoretically should have executed correctly before doing UB. That is, there is no "correctly" in a program that exhibits UB; either the program is correct, or it is incorrect.

How far that goes depends on the implementation, but as far as the standard is concerned, VS's behavior is consistent with the standard.

the Y-combinator only works with one parameter and combine needs 2

Any multi-argument function can be imagined as a one-argument function, returning a lambda that waits for the next argument. This process is called currying. For example, if we have

You say you understand this definition:

Early versions of OCaml happily accepted types such as type t = t -> int. They even inferred them. The problem with that was that in most of the practical cases, such a type just masks a programming error. So by popular demand, they were disallowed, and you now need to need an explicit datatype. You can still get the old behaviour if you use the -rectypes option with the compiler.

That was merely a pragmatic decision. There is no semantic problem with such types, at least not in a language like OCaml.

Data types do not need to have non-recursive constructors as "leaf" cases, as long as the type of at least one constructor includes values that do not require another value of the defined type.

For example,

A binding construct in which the expressions can see the bindings doesn't require any exotic self-reference mechanisms.

How it works is that an environment is created for the variables, and then the values are assigned to them. The initializing expressions are evaluated in the environment in which those variables are already visible. Thus if those expressions happen to be lambda expressions, then they capture that environment, and that's how the functions can refer to each other. An interpreter does this by extending the environment with the new variables, and then using the extended environment for evaluating the assignments. Similarly, a compiler extends the compile-time lexical environment, and then compiles the assignments under that environment, so the running code will store values into the correct frame locations. If you have working lexical closures, the correct behavior of functions being able to mutually recurse just pops out.

Note that if the assignments are performed in left to right order, and one of the lambdas happens to be dispatched during initialization, and then happens to make a forward call to one of lambdas through a not-yet-assigned variable, that will be a problem; e.g.

A “tail call” will allow you to exceed any stack size limitations. See Programming in Lua, section 6.3: Proper Tail Calls:

...after the tail call, the program does not need to keep any information about the calling function in the stack. Some language implementations, such as the Lua interpreter, take advantage of this fact and actually do not use any extra stack space when doing a tail call. We say that those implementations support proper tail calls.