The functions definable in untyped lambda calculus are the computable functions, for which it is in turn possible to define equivalences to the concepts of Turing machines, recursive enumerability and Type-0 grammars.
But what about typed lambda calculus -- where on the Chomskian computability hierarchy are the functions definable by expressions of simply typed lambda calculus?
That is assuming that there is a natural way of transferring the idea of lambda-definability of a recursive function from untyped to simply typed lambda calculus, along the lines of:
A $k$-ary number-theoretic function $f$ is simply-typed-lambda definable iff there is a simply typable $\lambda$-term $P$ such that for all $x_1, \ldots x_k$, where $\underline{x}$ is the encoding of $x$, $P \underline{\vec{x}} =_\beta \underline{y} \text{ iff } f(\vec{x}) = y$, if $f(\vec{x})$ is defined, and $P\underline{\vec{x}}$ has no $\beta$-normal form othewise.
--- Transition from number-theoretic functions to formal languages ---
As pointed out in the comments, in order to apply lambda calculus to the concept of formal languages at all, one will have to ensure that the respective data types are actually expressible. Here are my thoughts:
I am assuming here Curry-style simply typed lambda calculus with no primitive types or constants, only term variables in the language and type variables in the type system.
- Letters of the alphabet can be mapped to natural numbers by a simple enumeration,
- Numbers can be encoded in lambda calculus e.g. via Church numerals,
- Strings can be encoded as lists (using constructions such as $\text{cons}, \text{head}, \text{tail}$)
- Booleans can be represented as Church booleans,
- Boolean functions can be constructed using the if-then-else combinator, taking as an input the result of some number-theoretic function argument and outputting a truth value,
all of which, as well as the applications arising in the construction, are (as far as I can see) simply typeable, so that it is possible to define a lambda term that takes as an input an encoding of a string and returns as an output a boolean value.
The interesting question then is, it seems, what exactly can happen (i.o.w.: what is definable) in the if-then-else combinator to sort the wheat from the chaff, in such a way that the function term expressing this algorithm is still simply typable.
With this, I guess my question becomes:
Between which levels of the Chomsky hierarchy is the class of languages located such that $L$ is in the class iff there is a simply-typed-lambda-definable function $f$ such that $f(w)$ is defined if and only if $w \in L$?
With that, do we even need booleans, or is it enough to have a function do whatever to its input and we only need to distinguish whether or not it reduces to any normal form at all, independently of the type of the output?
In case I made a mistake in my encoding idea, the additional question arises of whether simply typed lambda calculus is capable of performing an appropriate encoding at all, where in the negative case the answer would be that there is simply no such definable function $f$ and hence the class will be empty?
--- Alternative formulations ---
Alternatively, are there other ways of building a correspondence between typed lambda calculus and formal languages or automata that makes it possible to locate it on the known computability scale in a meaningful way?
Or other interesting intuitions about the computational power of typed lambda calculus, other than that it is decidable?
All I could find so far was about modifications of lambda calculus corresponding to certain types of grammars, or automata to recognize strings of certain kinds of lambda expressions, but, surprisingly, nothing specifically about the computability complexity of typed lambda calculi.
I am primarily interested in Curry-style simply typed lambda calculus, but if there is anything interesting to say about e.g. polymorphic typed lambda calculus, I would be happy to learn about that, too.
