> That said, I consider Haskell to be a Lisp language.

Then Lisp (aka 'List processor') has lost its meaning.

Haskell is at its core a lazy evaluated, statically typed, purely functional programming language.

Lisp is none of that. The core of Lisp: an eager evaluated, dynamically typed, programming language supporting imperative, procedural and non-pure functional programming.

> But, Haskell was designed from the ground up, from ML, to be as it is.

Haskell was designed to have a common lazy language, instead of a dozen languages under development or in use (Miranda, Lazy ML, Clean, ...).

Why is Haskell a lisp? It is the first time I hear someone classifying Haskell in the “List Processing” family of languages, and although it does process lists I thought its main paradigma symbol and code representation goes in a complete different direction, more into pure function oriented programming.

When people say something "is a Lisp" that usually has little to do with list processing. It's about whether it inherits more from lambda calculus than from Turing machines.

Lisp literally stands for 'List Processor'. To claim that it has little to do with it, is really really strange. One of the main reasons to create Lisp was being able to compute with 'symbolic expressions', represented as linked cons cells in the form of lists...

McCarthy about Lisp:

===

As a programming language, LISP is characterized by the following ideas:

computing with symbolic expressions rather than numbers, representation of symbolic expressions and other information by list structure in the memory of a computer, representation of information in external media mostly by multi-level lists and sometimes by S-expressions, a small set of selector and constructor operations expressed as functions, composition of functions as a tool for forming more complex functions, the use of conditional expressions for getting branching into function definitions, the recursive use of conditional expressions as a sufficient tool for building computable functions, the use of lambda-expressions for naming functions, the representation of LISP programs as LISP data, the conditional expression interpretation of Boolean connectives, the LISP function eval that serves both as a formal definition of the language and as an interpreter, and garbage collection as a means of handling the erasure problem. LISP statements are also used as a command language when LISP is used in a time-sharing environment.

===

http://jmc.stanford.edu/articles/lisp/lisp.pdf

'lambda calculus' wasn't even explicitly mentioned. But he mentions s-expressions, list structure, multi-level lists, ...

The Lisp community has moved on from McCarthy's taxonomy. In McCarthy's day, there were two high-level computer languages (Lisp and Fortran) and now there are thousands. Today we have different notions of what constitutes a "Lisp-like" language and what doesn't. By McCarthy's strict definition, Clojure is not a Lisp because it doesn't use real cons cells. But I think most people nowadays would agree that Clojure belongs in the Lisp family more than in the Algol family.

Haskell has (very!) first-class functions and is even more naturally compositional than most "classical" Lisps. It feels to me like a Lisp with static typing, laziness, and automatic currying cleverly incorporated.

Likewise Javascript. Javascript feels like a Lisp to me because it has lexical closures. It gets in my way because its syntax and many other design choices are terrible, but it still feels like it descends from lambda calculus.

I guess my point is that whether a language is a Lisp or not can't be reduced to a simple list of bullet points.

Neither Clojure, Haskell nor Javascript are Lisp. Haskell and JavaScript are not even directly derived from Lisp.

Your idea of Lisp lacks any concrete features and suddenly all languages would be Lisp: Prolog, Haskell, ML, SML, Javascript, Java, ... all of them have sone form of functions.

This then is arbitrary. Lisp is a family of languages which share concepts and code. There are a number of concepts (you call it bullet points) which make a language a member of the Lisp family in a wider sense and it may not be that all members share all concepts, but MOST and the important ones,

Haskell for example is very very different from Lisp: syntax, semantics and pragmatics. There is no way one would consider Haskell a member of Lisp languages. Lisps are not statically typed, they are not lazy, they don't use currying, they are not side effect free, etc. If a languages has all these features at its core, it's not Lisp. Claiming that it is Lisp is just creating confusion. Give a student a Lisp book (say Peter Norvig's PAIP) and a Haskell compiler: nothing runs, the concepts and architectures are different, the development style, basically everything.

Pure Functional Programming has been split from Lisp decades ago in the 70s and 80s and we have now thousands of language camps (not just two: Fortran and Lisp). The core of Lisp is still the same:

List processing, dynamically typed, a specific form of evaluation, garbage collection, s-expressions with symbols, code represented as s-expressions, built-in code transformations over s-expressions, procedures are called functions, higher-order functions, eager evaluation, optional interpretation of code in the form of s-expressions, interactive development with read-eval-print-loops, etc etc.

From there new languages families have been forked or maybe only influenced: purely functional PLs (Haskell), logic languages (Prolog), object-oriented languages (Smalltalk, Self) and many others.

Smalltalk is also not Lisp, even though it got stuff like images, GC, blocks, interactive interface, and others via Lisp influence...

Haskell is "lispy" because it's based on lambda calculus

You are missing quite a bit of context on the history of Haskell. From https://www.microsoft.com/en-us/research/publication/a-histo... , it seems that Haskell's design did not arise out of Lisp, but out of several languages in the early 80s which were lazy/non-strict and purely functional.

Indeed, removing parents ruins the perception of Lisp languages as just another language family, and promotes Lisp into some sort of privileged position. Simultaneously, mistaking Haskell for a Lisp means mistakenly thinking that Haskell has special meaning for pairs over tuples or lists, that Lisps are statically typed or that Haskell is optionally typed, that Haskell has macros, that Haskell's juxtaposition-based application syntax is related to Lisp's parenthesis-based application syntax, and so on.

Consider example Lisp memes: "Data is code; code is data," or "all structures are lists." Compare with example ML memes: "If it compiles, it works," or "well-typed programs don't go wrong." Or even better, with Haskell memes: "Laziness leads to purity," "monads are programmable semicolons," "show me your types."

The only meme common to these communities is "lambda the ultimate", and you are ignoring decades of Lisp philosophy if you nominate this meme to carry the flag for all of Lisp. When I first read this comment tree, I wondered if everybody had forgotten about the Land of Lisp and the Republic of Haskell: http://www.lisperati.com/landoflisp/panel01.html

I consider Haskell to be an ML, and even then, it's worth remembering that lazy/non-strict MLs have different behavior from the rest of the family.

Isn't homoiconicity one of the requirements for a lisp? If so, that makes Julia a lisp, but not Haskell.

Completely agree. Haskell is IMO the only paren-free Lisp that works. As you said, it was designed that way from scratch, not as an afterthought from s-expr syntax. I also think automatic currying and pervasive laziness contribute a great deal to making the parens unnecessary, and most Lisps don't work that way.

> Haskell is IMO the only paren-free Lisp that works.

Out of curiosity: Do you think Julia is not a Lisp, or that Julia doesn’t work?

I know Julia was originally a Lisp and it incorporates a lot of Lisp ideas, but I've never used it so I have no opinion about how well it works.

Lots of Lispers consider Javascript a (primitive) Lisp because it has lexical closures, but I think its syntax is horrible and thus (IMO) it doesn't "work."