It's spelled 'Lisp'. There has been zero overlap between people writing "LISP" and people writing lisp code for about half a century.

That's really overstating it, especially seeing as Lisp has barely existed for half a century, and people like ESR call it "LISP" to this day.

AFAIK the allcaps "LISP" fell out of favour in 1984 when Common Lisp was introduced, and only the original Lisp implementation and Mac Lisp used the allcaps name.

Much like Fortran (no longer FORTRAN), the acronyms became proper names in their own right.

Someone pointed out that Common Lisp is case-insensitive by default, so really they have no grounds to object to the name LISP. ;-)

The CL reader by default[1] converts unescaped characters to uppercase, but only when parsing tokens. The CL printer by default[2] converts everything it prints to lowercase. CL people seem to adopt these conventions as well, although they have been known to :capitalize Lisp on occasion.

[1] http://l1sp.org/cl/2.2

[2] http://l1sp.org/cl/*print-case*

    CL-USER 30 > (eq '|LISP| '|Lisp|)
    NIL

Common Lisp knows very well the difference between LISP and Lisp

English is the relevant rule set here, not Lisp :)

You're wrong, and you need to get off your high horse. People use "LISP" when referring to the general family of LISP-like languages. And people that do this tend to know about Common Lisp. That's why they do this.

> LISP's also has a long history of popping up all over the place because they are extremely implementation-friendly

This is a LIE.

I get tired of hearing this over and over. Broken Lisps are easy to implement.

Try implementing a real s-expression parser in C. I'll wait.

For example, this library: http://sexpr.sourceforge.net/ takes 5000+ lines of code. And it doesn't even handle dotted pairs! (For good reason, handling dotted pairs without recursion is extremely difficult.)

I have written entire languages in that number of lines. So, have many others.

Lisp does not count as small.

I'll be the first to agree with you that most 'minimal' lisp implementations are going to be missing important features (efficiency, memory management, ..), but is the parsing of s-exprs comparatively a difficult task?

At just a glance, it appears that the library is slurping the expression and avoiding recursion instead optimizing for speed, memory usage, and error reporting, but it seems like you could implement a recursive descent parser if you weren't as concerned with those. If the author took their same approach to parsing s-exprs for a grammar like C, I'm not sure how successful they would be.

I haven't really looked at grammars / compilers in a long time, but I'm curious if I'm off-base in thinking s-exprs are relatively easy to parse. Some grammars like brainfuck or assembly would obviously be easier.

There is nothing difficult about writing an s-expression parser. None of the plethora of Scheme interpreters out there get parsing wrong. Handling dotted pairs is rather trivial compared to, say, getting hygienic macros right. Or implementing call/cc. Quasiquote handling is not even that difficult.

> There is nothing difficult about writing an s-expression parser.

Really? Try it in C.

The Scheme interpreters do very limited dotted-pair parsing until they bootstrap into scheme. There is a good reason for this.

And this is before we even start dealing with things like circular references.