
ABCL – Common Lisp on the JVM - simonpure
https://common-lisp.net/project/armedbear/
======
owyn
I poked around a bit to figure out why this was even posted and there was a
new release 1.6.0 on November 22nd which adds support for jdk 11, among other
minor things. ABCL provides a java class which can load/eval lisp code, and
the ability to call java classes from your lisp program, stuff like that.

[https://abcl.org/svn/tags/1.6.0/CHANGES](https://abcl.org/svn/tags/1.6.0/CHANGES)

As an "old" I learned LISP in college but have never had the opportunity to
use it in my career. Still on my todo list!

~~~
awayfromhomenow
Don't do it, you'll hate every other language after that (I do).

~~~
shpongled
I like LISPs conceptually. However, I have a strong preference for static type
systems, so I have probably written 10x more lines of code of LISP
implementations than LISP code itself.

~~~
jsjolen
Racket has Typed Racket, you might want to try that out!

~~~
TurboHaskal
Have you tried it yourself though? That thing is so slow it's barely usable.

~~~
jsjolen
Is it the type checking or the runtime that's slow?

------
dang
A well-established implementation, but there haven't been many HN threads.

Just this from 2009:
[https://news.ycombinator.com/item?id=930514](https://news.ycombinator.com/item?id=930514)

and a bit from 2017:
[https://news.ycombinator.com/item?id=14605334](https://news.ycombinator.com/item?id=14605334)

~~~
lispm
It's also mostly a full implementation of the Common Lisp standard with
extensions, which is quite an achievement.

------
chrisseaton
I'm amazed it literally has a class

    
    
        public final class Cons extends LispObject
        {
          public LispObject car;
          public LispObject cdr;
        }
    

I would have thought it would provide that abstraction to the programmer but
use another representation internally. Chasing pointers like this on modern
hardware is surely crazy?

~~~
ts4z
A lot of things in Lisp force the implementation of lists as cons cells. It’s
probably possible to do something different, but no one has, and the result
won’t be a Common Lisp.

(Consider that the detail of improper lists is enshrined in the language.)

~~~
lokedhs
Common Lisp does have proper arrays as well, which can be used if the
situation calls for it.

As it turns out, arrays aren't actually used that much (except for strings of
course) in CL code. Most lists are just a few elements long, and regular lists
are perfect for that.

~~~
ts4z
The structure of a list is still exposed, and that decision is baked into the
essence of Lisp. If you have a list, you cannot substitute a skip list or an
array. If you have a skip list, it is (I think) not a language-level sequence
and so things like rest and nth won’t work on it.

Arrays, struts, all other things are possible, but the things that make Lisp
Lisp mean that you may get a list where repeatedly calling cdr may result in
something that is not listp (cons or nil). And that’s weird. It enables some
things that are wonderful, but I think the Lisps are practically unique in
conflating pairs and list elements.

~~~
ts4z
I bet CL allows generalizing nth and cdr. My point is still that the list
structure in Lisp is very baked into the language.

~~~
lispm
Common Lisp has a standard abstract data structure called 'sequence' and
generic operations for it. Sequences are either vectors or lists. Vectors are
bit vectors, strings, general vectors, ... Sequence operations are then
supported for all subtypes of sequences.

[http://www.lispworks.com/documentation/HyperSpec/Body/c_sequ...](http://www.lispworks.com/documentation/HyperSpec/Body/c_sequen.htm)

There are some problems with this design. The main motivations for it were:

* basic operations in Lisp are type specific, one wanted to have some generic operations and a generic sequence abstraction over lists and vectors

* the low-level data structures like conses, arrays, tables are not object-oriented and generic

* generic operations in a dynamically typed language are slower, since there is always a runtime dispatch necessary

* to remove runtime dispatch one can use type declarations (which are optional in Common Lisp) or a JIT compiler (which is not used in most implementations, they do AOT compilation)

* the language at the type of this design had no agreed OOP extension - CLOS came some years later -> sequences are non-extensible and don't support adding new sequence types

The design of this was later improved in languages like Dylan: see the
Collections of Dylan

[http://lispm.de/docs/prefix-
dylan/book.annotated/ch12.html](http://lispm.de/docs/prefix-
dylan/book.annotated/ch12.html)

Recently some CL implementations experiment with extensible sequences.

[http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-...](http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf)

------
JimmyRuska
Besides clojure, might be worth noting;

kawak - scheme for the JVM
[https://www.gnu.org/software/kawa/](https://www.gnu.org/software/kawa/)

bigloo is a scheme can compile to C. I think it can also make java class files
with bindings [https://www-sop.inria.fr/mimosa/fp/Bigloo/](https://www-
sop.inria.fr/mimosa/fp/Bigloo/)

~~~
Per_Bothner
Just "Kawa" \- not "kawak".

(There is actually a very-incomplete Common Lisp implementation as well in
Kawa, but the Kawa Scheme dialect is the main Kawa language.)

(Hoping to make an official Kawa 3.1 release by the end of the year - but no
promises. Until then, use git HEAD.)

------
kick
The title of this post should be changed to "Armed Bear Common Lisp - Common
Lisp on the JVM." It's an iconic name, and then people would actually know
what the post title was referring to.

~~~
twic
I guessed it was Aluminium Bank Common Lisp, some kind of lightweight version
of Steel Bank Common Lisp.

~~~
tempodox
That's actually a nice pun with a good explanation, while Armed Bear only
raises questions for me. What kind of weapon would you arm a bear with? Why?
Aren't bears unassailable enough as it is?

~~~
twic
Bears are most commonly armed with 87.6 mm artillery:

[https://en.wikipedia.org/wiki/Wojtek_(bear)](https://en.wikipedia.org/wiki/Wojtek_\(bear\))

It seems it's the author's brand name for software, and is a pun on the US
constitution's second amendment:

[http://armedbear-j.sourceforge.net/](http://armedbear-j.sourceforge.net/)

We may thus infer that you would arm bears because of the threat of armed
bears. After all, to stop a bad bear with a gun, it takes a good bear with a
gun.

------
nextos
A bit off topic, but is Common Lisp still a good choice?

I spent a lot of time learning and coding CL during the last decade. I love
lots of things about the language. Overall, it's great it's true
multiparadigm. Few languages achieve that.

However, the implementations are too fragmented which makes the standard quite
stagnant. And libraries are falling a bit behind.

I love Clasp is putting CL on top of LLVM. I wish we could have something with
the best ideas of Racket, Clojure and CL on the LLVM.

~~~
na85
>A bit off topic, but is Common Lisp still a good choice?

As always, it depends on your application. For instance I decided recently
that I would work my way through the cryptopals challenges, and opted to avoid
Lisp since bit-twiddling is such a pain in that language.

~~~
p_l
Since bits are addressable directly in Common Lisp, I found the language to be
very very nice for bit twiddling. Maybe you're mixing it up with Clojure? (bit
twiddling in clojure without extra libs is a PITA).

------
edko
What would be the best way to get (free) IDE support?

~~~
Arcsech
Emacs with SLIME is probably your best bet, as with most other Common Lisp
implementations.

