That's a fairly non-standard definition of functional programming, for two reasons.
First, it's not the definition most people use for "functional programming". From Wikipedia:
> In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program.
> In functional programming, functions are treated as first-class citizens, meaning that they can be bound to names (including local identifiers), passed as arguments, and returned from other functions, just as any other data type can. This allows programs to be written in a declarative and composable style, where small functions are combined in a modular manner.
Second, aren't all languages based on lambda calculus, if you squint hard enough?
Also lisp isn't actually based on the lambda calculus (for one thing the lamdba calculus doesn't have recursion!! (besides through the Y combinator). Lisp is also evaluated in a very different way than the lamdbda calculus. Lisp has a syntax to declare function literals which takes its name from the lambda calculus, and you can express the lambda calculus relatively cleanly in lisp (i.e. you can write lambda expressions in syntactic lisp) but that's really the only connection.
I don't think that's true when lambda calculus is regarded as a "library" of certain objects and concepts added to mathematics. Then the assignment operator is available.
You've probably seen the Y combinator given similarly to:
Y = λf.(λx.f(x x))(λx.f(x x))
where this Y = business isn't part of lambda calculus per se, but it's available because this is mathematics; existing mathematics notation that doesn't conflict with lambda calculus, like being able to equate a symbol and expression, hasn't gone out the window.