They can't be written in Lisp well, or at all. Strong typing with inference can't be bolted on. Monads that take advantage of this typing can't be bolted on. Changing Lisp to have lazy semantics across the board ain't gonna happen.
You might be able to write a Haskell interpreter from scratch that interacts with the Lisp environment, but you can't feasibly transform Lisp itself.
Nobody told Dr. Tarver[1]. He built a series of lisps with tight integration with the underlying Common Lisp platform featuring a strong typing system rooted in the propositions of Sequent Calculus[2][3]. Type delcarations are only on top level forms with all locals inferred. There seems to be work to improve this in Shen Professiona's new compiler. Shen offers tight integration with the underlying platform (although it has been ported to a number of runtimes (SBCL, CLISP, and V8 amongst others)[4]).
Usually when people say "you can do X in Lisp", they mean that you can integrate a feature into the language.
Don't have list comprehensions? Write a macro.
Don't have "thrush" syntax? Write a macro.
Don't have lazy evaluation? Write a... err. You can't write a macro[1]. You can't write something which completely changes the entire calling semantics of the language. What you can do is make a little sub-language which uses different values and objects from Lisp, but you can't magically make the standard library support lazy evaluation.
Same with types and type inference (a la Haskell).
Same with many other things.
Of course, obviously, you can write a compiler that compiles to Common Lisp, or C, or Scheme, or COBOL. But writing a compiler -- while Lisp is good at that -- isn't really taking advantage of what it usually means for Lisp to be extensible.
[1] For those who are ready to call out the many "lazy" libraries in Common Lisp, perhaps even my own, you're missing the point. You can make a new version of DEFUN and a new version of FUNCALL. But that doesn't make REMOVE-IF, SUBSEQ, MAPCAR, LIST, CONS, etc. lazy. As such, many, if not most, of the benefits that laziness brings, don't get applied to the language at large.
What are macros if not custom compiler extensions?
Sure, Shen is enough of a compiler extension to be its own language, but I can call Common Lisp code from Shen and call Shen code from Common Lisp. Doing either isn't very different from calling a native function (calling Shen from Shen is similar to calling CL from Shen).
As far as [1], I don't really see this as an issue with CL. CL has not made the effort to rewrite its core in terms of generic functions. If this were to be done, drastically changing CL's behavior for random new types would be relatively painless. But the way that the current CL standard chose for its library and core functionality isn't to use generic functions everywhere. As such, it is expected that if you drastically change implementation, you end up with separate functions. I think this is a huge draw of something like Clojure/JVM with its interfaces/protocols as a base level over a far more mature system like CL/SBCL.
Got to this late, but other commenters have already pointed out why this is wrong.
While this is unfounded (I have no sources), LISP is quite possibly the most flexible higher level language ever invented, I would caution against betting against it in the future.
Saying that it's the most flexible higher language ever invented might not actually amount to much -- I'm sure there's actually a small subset of features/points-in-the-language-that-allow-for-user-modifications that you need to achieve such high flexibility, but figured it was worth saying.
[EDIT] - My wording of the original post is sloppy. Where I say Lisp, I mean the dialect of Lisp that is Common Lisp.
Your argument doesn't add anything really. You can make anything in any reasonable language.
When people say "you can add X to Common Lisp" or "you can make X in Common Lisp", they usually mean that you can integrate such a feature in Lisp.
If you mean "you can write a compiler in Lisp", then, obviously. But you can do that in C++ too.
Not a single reply has demonstrated that you can effectively and reasonably add those features (to their fullest extent) to Lisp. They all replied saying that you can do things like write a new language (e.g., Shen), perhaps by using Common Lisp as your implementation language.
You cannot write a compiler that integrates into your language in C++ or Haskell. And it is trivial in Lisp, just wrap a compiler into a macro.
For example, my typical workflow heavily depends on Prolog blended into Lisp. I also use an ML implementation, also blended into Lisp seamlessly, and a subset of a Haskell-like language (lazy and strictly typed), also tightly integrated with Lisp, to a degree that it can access Lisp or ML local variables defined around the Haskell code block.
You cannot do this in any language which does not have proper macros.
You might be able to write a Haskell interpreter from scratch that interacts with the Lisp environment, but you can't feasibly transform Lisp itself.