See also ProgrammingConceptsNotPioneeredByLisp 

If Lisp is the king of all languages, and I don't dispute that, I wonder what programming concepts exist but aren't used by Lisp programmers, and why?
----
Since almost everything is implementable in Lisp, let's not weight down the page by mentioning it. What is interesting primarily are (1) the things that are almost universally available in a language implementations, and similarly (2) the things that are widely used by programmers in that language, and where appropriate (3) compiler help with a feature.

For instance, you can write Bignums in C, but you cannot use operators like + - * / with them, you must use functions instead, which also means you have to manage your own temporary results, and the code that uses Bignums gets ugly very fast. So it really makes a difference to have compiler support for certain features.

Lisp macros and custom eval functions and such are powerful but off-topic, because they are a means of creating language '''extensions''' and hence will not be part of every Lisp programmers toolkit. By this criteria, Prolog has unification but Lisp does not, despite the fact that unification has been implemented in Lisp.

P.S. Perhaps the dividing line is just whether a feature/concept only requires a truly trivial amount of work, like a one line function.
-----

Okay, that's an interesting question; I'll take a stab at this.
(I'll be dicussing CommonLisp).
Firstly, of course we have to distinguish what is meant by '''not found in'''.
Design by contracts is not found in lisp, but could be implemented in Lisp,
via the MOP.  Lisp is so flexible that most things fall in this category,
but I'll include them nonetheless.  So the followings which are not
present in a vanilla CommonLisp.

	* DesignByContract (at its best when the language can do reasoning based on the conditions, rather than simply testing them)
	* strict interface hiding (the private/protected/public stuff).  Runs against the philosophy of most (all?) lispers, so, though implementable, you're not likely to ever see it done.
	* multi threading (often found as an extension in many implementations, however ''Often enough to be mentioned here?'')
	* backtracking
	* inferencing
	* PointerArithmetic!
* Native prefix notation ''(what is this?)''
	* others?

Are these the sorts of things you were after?	--SmugLispWeenie

	* Prototypes
	* ''Everything'' is an Object, which implies that every function belongs to a class or prototype.

''Hmm?''
 CL-USER> (class-of #'car)
 #<BUILT-IN-CLASS FUNCTION>
''--MatthiasBenkard''

----
Some things were in the old lisp machines that aren't easily found now. 

* "areas" of memory where you could control things like how often the GC visited
* "stack groups" on which you could build processes, coroutines and generators for real multiprocessing
* "locatives" which are apparently GC-friendly pointers
* 65,536 processors: "A good Connection Machine is one that implements CmLisp quickly and economically." (Hillis, _The Connection Machine_)
* structure editors -- The Interlisp dialect was very IDE-oriented; sort of the anti-Emacs, in that it operated on program structure rather than text. You may find these ideas now in Simonyi's Intentional Programming. http://alu.cliki.net/AudioVideo#ip
* (perhaps modifying GCs? and support for multiple languages?)

Most of these were taken from http://bitsavers.org/pdf/mit/cadr/chineualJan84/
----

Footnote: It may be of interest, despite above comments, that some famous package has implemented something for lisp. Add such to this list:
* backtracking: ''''screamer'''' package
* inferencing: (list Prolog-like packages here)

----
RelocatableCode (of course you are going to ask why I need it. The answer is always along the lines of need to open up a process, allocate a memory buffer, copy program there, start it executing, and destroy original process)

----
Does lisp offer non-garbage collected memory?  For example, a competent C++ programmer can know exactly when a variable comes into scope, and when it goes out of scope (triggering a destructor) and therefore has its memory available for use again.  Garbage collection hides the release of memory from the programmer.  In other words, does lisp offer any way for the programmer to know exactly when memory will be released after the programmer states that it is no longer needed?

----

Correct me on any of these:
* Continuations, coroutines
* Currying (such as "f 3 where f = (+) 1" in Haskell)
* Lazy Evaluation
----
Scheme was the first language to implement first class continuations actually.
CategoryLisp