OpenLDK: A Java JIT compiler and runtime in Common Lisp
github.com
github.com
Besides, there's more to Lisp than Clojure.
However, some Common Lispers will refuse to code switch[1] when around non-Common Lispers, with the implicit assertion that Common Lisp is the only true Lisp. This is, of course, just gatekeeping snobbery.
When normal people say "Lisp" they're referring to a group of languages which includes Scheme, Clojure, Racket, Janet, Emacs Lisp and of course, Common Lisp, and probably a few others.
To be clear, not all Common Lisp folks are like this. The vast majority are very nice people. But there are enough bad apples that you'll inevitably run into this "correction" if you discuss Lisp dialects publicly for long enough.
I made a Lisp. It's not Common Lisp, yet I've never had anyone tell me it's not Lisp.
I believe Clojure is better than AutoLISP.
I wouldn't use McCarthy's LISP 1.5 for anything; it mainly of historic interest. But it is undeniably Lisp.
"Lisp or not" is not the same thing as "good or not". It's more like "different or not". Difference is what makes certain words apply to some things and not apply to some other things.
This is not some gender issue of inclusivity, like what is a woman. It has nothing to do with being nice or not. It's a technical matter of using the correct term for the things to which it applies.
Please tell me you aren't making the argument that things with "Lisp" in the name are Lisps.
If only Steele and Sussman had thought to call it SchemeLisp instead of just Scheme, we could have avoided this whole semantic debate.
> I made a Lisp. It's not Common Lisp, yet I've never had anyone tell me it's not Lisp.
Me too! I've never had anyone tell me anything about the Lisp I made, actually.
> This is not some gender issue of inclusivity, like what is a woman. It has nothing to do with being nice or not.
Respectfully, I disagree. Being pedantic isn't nice, and this "Lisp refers to Common Lisp" idea was explicitly about politically excluding Scheme from the community all the way back when Naggum started it[1].
> It's a technical matter of using the correct term for the things to which it applies.
The problem with what you're saying is that words apply to concepts based on usage, not based on what a small group of pedants think they should apply to.
De facto people apply the term "Lisp" to both Scheme and Closure, therefore the term applies. That's how the English language works, words that are widely applied to a thing are taken to mean that thing. And sometimes the meanings of words change over time because common usage changes. Like it or not, common usage moved beyond "Lisp" meaning... whatever you want it to mean. People refer to Clojure as a Lisp now.
[1] https://web.archive.org/web/20250000000000*/https://groups.g...
Their use of Lisp is not big enough to count as English mainstream. Neither is any other use of Lisp in computing.
English mainstream "Lisp" is the speech artifact.
When the following groups use the word "Lisp", they all mean something else: (1) hackers working in some classic Lisp; (2) Clojurians; (3) speech therapists.
The Clojurian "Lisp" does not include anywhere near everything from the classic "Lisp", and vice versa.
The Clojurian "Lisp" is mainly just a synonym for Clojure, and in a broader sense refers to Clojure-like dialects like ClojureScript, Babashka and such.
Clojurians use the word "Lisp" because the Clojure website and documentation tells them to. If the Clojure website and documentation spelled it out that Clojure takes some ideas from Lisp, but isn't Lisp, then they wouldn't do that.
The author of Clojure despises classic Lisp and Lisp hackers, so he perpetrated that on purpose, and gleefully enjoyed it when some Lisp programmers become indignant about it.
Problem is, it does cause confusion. It's not as simple as these people have their "Lisp", these others have theirs, because the usage is in a very similar area. We see situations like people not wanting to try a classic Lisp because they think it's a functional language for manipulating immutable data structures due to either their exposure to Clojure or to Clojure-related advocacy. That could work the other way; people who don't like classic Lisps (e.g. passing familiarity from school years) may be reluctant to try Clojure thinking it's the same, since it calls itself Lisp!
In the Perl community, calling a certain different, new language Perl 6 created confusion. So the creators did a kind thing and invented a different name: Raku. This is because they didn't despise the Perl user base; they liked Perl users and wanted to be helpful.
Wow, you've gotten really specific with your straw man argument here.
I'm sure you can find some wacko out there who specifically is saying that's what a Lisp is, but that's certainly not what I'm saying a Lisp is. The Clojure front page says:
"Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system."
Maybe try responding to a more mainstream opinion like that instead of your straw man.
> Clojurians use the word "Lisp" because the Clojure website and documentation tells them to. If the Clojure website and documentation spelled it out that Clojure takes some ideas from Lisp, but isn't Lisp, then they wouldn't do that.
Wow, life must be really hard if you're triggered this easily.
Alternative hypothesis: Clojure docs refer to Clojure as a Lisp because it is obviously a Lisp, not because they're picking on poor persecuted Lispers. You're not a martyr. Nobody in the Clojure community cares about your feelings enough to try to hurt them. In fact, for the most part, the Clojure community doesn't know you exist.
If you can find a spot where Clojure website or docs orders Clojurians to refer to Clojure as a Lisp, I'll be pretty surprised. My guess is, all it does is refer to Clojure as a Lisp. It's not about you, so maybe try and cope by not taking it personally.
> The author of Clojure despises classic Lisp and Lisp hackers, so he perpetrated that on purpose, and gleefully enjoyed it when some Lisp programmers become indignant about it.
I very much doubt Rich Hickey "despises classic Lisp and Lisp hackers", given he wrote a language which you have to admit is at least heavily based on Lisp.
I won't speak for whether Rich Hickey feels glee because I don't make shit up like you are, but I feel glee when pedants get triggered, and I think that is pretty justified. :)
To be clear, I don't hate Common Lisp programmers--I like Common Lisp and most of the people who write it.
Rich Hickey did say that a lot of Lisp communities are really toxic and he wanted to distance the Clojure community from that and... yeah, you're being a great example of his point.
> We see situations like people not wanting to try a classic Lisp because they think it's a functional language for manipulating immutable data structures due to either their exposure to Clojure or to Clojure-related advocacy.
Maybe people don't want to try a classic Lisp because they start exploring the possibility and all the communities are polluted with gatekeeping pedants.
And let's be explicit: is Scheme a Lisp? I know you're just parrotting Naggum's arguments against Scheme, so let's be clear: this isn't about Clojure, this is part of a gatekeeping culture that started before Clojure existed.
Other known examples of Lisps are Emacs Lisp, Common Lisp and Scheme.
Common Lisp is fun to code in, and the tooling is top-tier.
Common Lisp implementations like SBCL have static typing, performance, instant (and effortless) compilation to native machine code, and so on. No need to deal with Leiningen or copy-pasting a deps.edn / build.clj template across projects. If I want to experiment with SIMD intrinsics with the comfort of a REPL, I can't do that with Clojure, but I can do that with SBCL and a built-in library (SB-SIMD).
Note: I have used Clojure professionally and still use it for some personal projects, but I try to be aware of the trade-offs when deciding to use Clojure / Common Lisp / any other programming language.
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
I am old enough to remeber the days any junior Assembly programmer could easily outperform any machine code generated by the C compilers of the day.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/
...including Common Lisp.
A Java runtime... running on a Java runtime... Hmm, maybe not. But could be possible.
https://winworldpc.com/product/ibm-visualage-for-java/10
QUOTE: VisualAge for Java is based on an extended Smalltalk virtual machine which executes both Smalltalk and Java byte codes. Java natives were actually implemented in Smalltalk. Later versions were implemented on regular Java.
Obviously not the same....
> A Java Virtual Machine and Bytecode-to-IL Converter for .NET
Joke aside, that is an amazing project.
example: we could have a `case` that works as follows and adheres to Scheme/Lisp style (using parentheses to clearly specify blocks):
(case name
(is_string? (print name))
(#t (print "error - name must be a string"))
)
(case name
is_string? (print name)
#t (print "error ...")
)
Notice that I'm not saying we should use indentation—that part is just cosmetics. in the code block above, we simply parse case as an expression with a scrutinee followed by an even number of expressions.
Alternatively, one might use a "do" notation to avoid using (do/begin/prog ...) blocks and use a couple more parentheses:
(for my_list i do
(logic)
(more logic)
(yet more logic)
)
See e.g. cond in clojure: https://clojuredocs.org/clojure.core/cond
Clojure also reduces parentheses by introducing more characters for various data-structures (good and bad, many would say), like [] for vectors, which are for example used for arguments when defining functions
(def add-five [a]
(+ a 5)) (loop for i in my-list
do (logic)
(more logic)
(yet more logic))So, in pseudocode:
(print (+ 1 2))
(exit 1)
print (1 + 2); // "+" is the 2nd place because it's a method call on "1"
exit 1;
For function bodies, I also introduced an extension to make lambdas stand out more from the rest of the code by using curly braces:
(0 to 10) loop ^(i) {
print i; // Internally transformed to (print i)
}
// clarification:
// 1. The "to" method of the 0 object creates a Range object, which has a "loop" method that accepts a lambda.
// 2. The ^ symbol is just a shorthand for "lambda".
(typecase name
(String (print name))
(otherwise (print "error: name must be a string!")))
(defmethod namecall ((name String))
(print name))
(defmethod namecall ((name Number))
(print "I am not a number, I am a free man!"))Plus, the capitalized type name reminded me of Coalton[1], which is an internal DSL for CL that implements ML-style type system. There, the dispatch on a type (conventionally named by a capitalized symbol) happens statically.
There are a lot more hairy/pressing issues given how old the CL spec is (the type-system esp. comes to mind).
the parens are just a textual representation of a tree. once you have a proper editor, then the eliminated parens actually become an obstacle.