Originally, the term Lisp referred to the language which was the brainchild of John Mc Carthy.
Nowadays, when unspecified, the term Lisp either refers to Common Lisp (a language), or the Lisp family of languages, all of which share the Lambda Nature (see Language Families).
A less strict criterion for inclusion of a language into the Lisp Family is the use of parenthesized lists to represent a program, and manipulation of lists made of two-field cells that can be manufactured and connected by a function called CONS (see Cons Cells). It's somewhat of a custom that whenever someone writes a one-weekend interpreter for such a language, it is given a name that includes the word "Lisp". (Never heard of that - where is that?) Much newbie confusion arises from all of the different things that are called Lisp but have nothing to do with the mature, complex, super-powerful Common Lisp, which, as the result of the combined efforts of the dominating lisp communities, is seen by many as the only thing that should be called Lisp (see The Evolution Of Lisp).
'SEXP-Syntax is neither sufficient nor necessary' for a Lisp dialect.
The sharing of the CONS function is something I borrowed from a paper by Kent Pitman in which he tries to pin down what exactly makes something Lisp. (See www.nhplace.com 
. Also see Parenthetically Speaking.)
There, he also argues that there is no lambda commonality among things calling themselves Lisp; the syntax varies - some things don't have lexical closures, others closures that can only be passed down, not returned, etc. Lambda Nature cannot exist without lexical scoping, so that the Lambda Expression creates a function-object that has captured the lexical bindings.
Why is Lambda Nature dependent on lexical scoping, given that lambda is so much older than Lisp lexical scoping?
But note that I disagree with this paper on the whole; Pitman believes that there is a Lisp Family, but that it arises out of some vague cultural connections rather than any specific language features. I view myself strictly as a Common Lisp user, and nothing more. I stay away from anything else that resembles Lisp, and don't feel that I belong to any broader community. Communities based on sharing a programming language are a fiction. Two people who don't know each other at all, but just happen to use the same programming language, text editor, operating system or whatever, are not automatically a community! That they can be is just some touchy-feely thinking thinking that might be called Techno Collectivism. Or maybe it's a spinoff idea from Brand Identification that westerners grow up with. If you drive a certain make of car, you are suddenly a member of the group of people who drive that car, and somehow this is more than just a dry mathematical observation that places you in a set. But really, to have a community, you must have a group of individuals who identify together in some concrete way, and actually know and recognize each other. I might form a community with some CL users, but not all of them at once!
Paul Graham provides another reasoning what defines Lisp. See www.paulgraham.com
Gerald Sussman and Guy Steele named their dialect Scheme at a time when it was fashionable to give each Lisp dialect their own name (MDL, T, NIL, Conniver, and so on). Note that in the original papers about Scheme, Scheme is always described as a Lisp dialect. Further note that today's Scheme looks remarkably different to the original Scheme. Further further note, that the original Lisp didn't have lexical closures but that they were introduced in a clean way in Scheme. The Common Lisp designers have taken the Lexical Closure concept from Scheme. (In turn, lexical closures were first defined in Algol Language.)
There are many reasons why to prefer Common Lisp over Scheme Language (see Lisp Scheme Differences), and vice-versa, but to describe Scheme as not being a Lisp is as simplistic as to say that Scheme and Lisp are more or less the same. The truth is somewhere in between.
I wouldn't care if the Scheme people take over the word Lisp, and the Common Lisp people then rename their language and stop using the word. The point is that the term is simply too diluted when it takes on too many meanings, and as such it has little value. We can't even agree on what Lisp means; so maybe there is no point in using this word? Yet somehow it seems so coveted that people get ruffled when someone dares suggest that their pet language is not Lisp. Maybe "Lisp" is just a synonym for "cool". So if you say that some language is not Lisp, you are really saying that it's not cool. Also, because "cool" is hard to define, "Lisp" is hard to define. Moreover, things that are obviously not Lisp at all are clearly uncool. I can't think of a single counterexample when "Lisp" does not mean "cool", except when it's used in the name of some concrete language or implementation. AutoLISP doesn't mean AutoCOOL, and Common Lisp doesn't mean Common Cool. But as an adjective, to say that something is Lisp simply means that it has hacker approval.
Okay, so how about this: Lisp as an adjective means "cool". Lisp as a noun that is part of a noun phrase designating a programming language adds the semantic attribute "language derived from cool ideas". And used entirely by itself, in the absence of historic context, it means "ANSI Common Lisp", where this second occurrence of Lisp is not subject to the cool-substitution, but simply stands for itself. In some proper historic context it means "the language invented by John Mc Carthy and peers". There, it's settled!
----
So, Lisp == cool? I thought that Csharp Language == cool! By transitivity, this implies that Lisp == C#
Amazing. And all this time I had thought that C#/Dot Net was little more than a blatant ripoff of Java (both the language and the platform)! Now we find it's really Lisp in disguise!
So, then why doesn't C# have Ess Expressions?
Ah, I think your "==" operator means, in this context, "is a member of the set".
No, "==" means equality. The development codename for the C# project at Microsoft was "Cool", one of the worst-kept secrets of the past couple years. The rest of the above section is tongue-in-cheek
So... when do you think we will see Microsoft Visual Lisp (or, for that matter, Visual Lisp Dot Net?????) What will the Lisp Hippies do if their favorite language is taken over by the Evil Empire? I guess it would make writing macros in Microsoft Excel more fun!
Well, long, long ago, there was already an MS Lisp...
groups.google.com
There is a Visual Lisp product from Autodesk for use with its popular AutoCAD software. Not surprisingly, the appearance of Visual Lisp coincided with the full-scale conversion of AutoCAD from a cross-platform tool into an application deeply rooted in, and heavily dependent on, the Windows environment (with ActiveX, etc.). -- Jeff Read
I hadn't noticed that it used to be heavily cross-platform. Anyway, just to avoid confusion: Auto Cad included Auto Lisp since 1985, and Auto Desk added the Visual Lisp programming environment for Auto Lisp in 1997. courses.home.att.net
----
A few things that might define some core of Lisp dialects and their typical implementation:
supports functional programming (LAMBDA, higher order functions, anonymous functions, local functions, APPLY, recursion, ...)
supports imperative programming (SETQ, BLOCK, TAGBODY, ...)
code transformation with macros
S-Expression notation as external notation for data-structures
Read Eval Print Loop for interactive programming
some form of automatic memory management
types declarations are optional
runtime generation and loading of source code
image-based programming environment
support for datastructures (symbols, functions, numbers, strings, arrays, conses, structures/classes, ...)
basic error handling
basic I/O with streams
Scheme extends this list by:
defined syntax
defined semantics
hygienic macros
continuations
lexical scope
tail-call optimization
Common Lisp extends the list by too many things to list:
declarations (types, compiler directives, ...)
multiple values
lexical scope as the default in addition to dynamic scope
Common Lisp Object System
compiler
extensive error handling (condition system)
more datatypes (extensive numeric tower, hashtables, streams, pathnames, ...)
environment functions (ED, INSPECT, DESCRIBE, TRACE, ...)
read-macros
Let's look at Dylan (the later Dylan):
declarations
lexical scope
object system built-in (simple version of CLOS)
error-handling
type-checking at compile time
Dylan lacks (despite its name) as a language the dynamic nature of the environment (though implementations are providing it as an addition): no read-eval-print-loop, no image-based development, no runtime code generation and no loading, ... Dylan also lacks the S-Expression syntax (the earlier Dylan version had it).
What do you consider the boundary between early-Dylan and late-Dylan? The switch to misfix syntax, or the demise of Apple Dylan? AFAIK, the original Apple Dylan had image-based development and a REPL loop. Gwydion Dylan lacked it because the Gwydion implementation was incomplete (funding pulled), but the original intent of the Gwydion project was to develop a state-of-the-art IDE that most likely would've included those features. Recent versions (2.3.10 and up) have added a REPL anyway. -- Jonathan Tang
Generally I see Dylan as a language with several implementations. There were implementations of both versions of the language (early Dylan was more Lisp-like, late Dylan was more static with a different syntax).
Early Dylan was a OODL (Object-oriented dynamic language). Basically, it was Scheme-like with the CLOS object-system (plus conditions, ...). The later Dylan was more concerned with efficient compilation and a mixfix (infix/prefix) syntax. It was also in many respects quite similar in spirit to Eu Lisp (an European attempt at an efficient and modern Lisp). Though I would say that Dylan is smaller and more monolithic than Eu Lisp. But Eu Lisp was the much better Lisp - compared to Dylan. As a Lisp programmer I liked the earlier version more - but Lisp programmers were not the target audience.
The Apple Dylan development environment was a bit unusual for an integrated Lisp system. (btw., It was not written in Dylan, but Common Lisp) Typically it had the source stored in a database and had remote connections to running Dylan applications. Though the GUI builder was written in Dylan and was running inside the remote Dylan application. So it is a bit similar in spirit (remote Lisp controlled by a foreign IDE) with Emacs-based IDEs for Common Lisp. Many Common Lisp IDEs are running inside the same image like the applications they are used to develop. One exception is CMUCL/Hemlock. There also is the idea of some 'slave' Lisp. I would say that the Apple Dylan environment was not very typical for a Lisp-based development environment - though it was a logical step from earlier systems.
The Gwydion team start with bold ideas of a novel programming environment. But they never got far in that direction. They were mostly busy implementing the language. For quite some time.
See original on c2.com