As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
There is LambdaCube which is written in Haskell (it's not exactly game engine but more like graphics engine).
You can always use f# or iron python (yes i do know, python isn't functional) or any other .netified language with XNA on .net platform.
edit: One more engine, written in Lisp: http://code.google.com/p/blackthorn-engine/
I don't have an answer to the question as written, but I believe you are possibly trying to ask "why aren't there more functional game engines" rather than looking for a specific one to use. If that's correct, you should rephrase the question. If not... ignore me. :)
A pure functional approach is not a good fit for games. Games (and graphics, and physics, and AI) and basically all about state changes. The correct functional approach to these problems would be to compute an entire new state once per loop, which will have a very severe performance penalty compared to coding more directly to how actual hardware works.
It is for that reason that you don't see any functional-style game engines in production. It is simply the wrong programming paradigm for the majority of problems a game engine is meant to solve. It is the wrong programming paradigm for the majority of problems that need to be solved in higher-level scripting and game logic code, too. While it is almost certainly possible to make a functional game engine, it would be slow, difficult and cumbersome to use, and would serve no real purpose other than being a neat demo/toy to show off.
Of course it can still be best to avoid functional approaches outside very specific circumstances since you want these offline tools to be as fast as possible. Functional languages excel at parallelism, which is good for some problems, but the abstractions from the hardware tend to lead to very inefficient single-threaded performance. (Languages like LISP do well here because they are not pure functional, and in fact Common LISP is multi-paradigm.) The absolute single worst thing for a game engine or related toolkit is to be a bottleneck for content iteration. A fancy engine with a lot of features that takes artists or level designers hours to do what could be done in 5 minutes (or ideally, near-instantly) will just lead to low quality games or cancellation due to budget escalation.
The Naugthy Dog company used List on its Game Engines and it was called Game Oriented Assembly Lisp.
Some information can be found here: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
It is not available for public usage.