4 ms·

I love Clojure and I think it's the first Lisp to take the language family out of "cons cell and parenthesis hell". My personal opinion is that Clojure with the

I love Clojure and I think it's the first Lisp to take the language family out of "cons cell and parenthesis hell". My personal opinion is that Clojure with the following changes would take over much of the Lisp space: - Rewrite most of Clojure in Clojure (which has been talked about since the beginning, really) to find the "small core". Thankfully ClojureScript has helped hasten the CiC movement. - Base FFI and code gen on more abstractions so that Clojure living in a .net world or a C/C++ world or a Python world would feel just as cozy as Clojure living on the JVM. Rich Hickey talked about why he abandoned primary CLR support early on. He said he "didn't want to keep writing everything twice". This was probably the best strategy at first, but now one hopes that with ClojureScript + Clojure enough has been learned to discover more ways to factor out the commonalities so that Clojure is more easily retargetable. - Speaking of targets: there should be a first class, fully supported Clojure frontend to LLVM. There are research projects and personal projects in this area, but that's about it. I'd like to see an official LLVM target. - Introduce or surface more abstractions and macros such that the immutability and pure functional underpinnings could be extended, removed, or replaced. This is likely to be the most controversial change, but it would be essential to the possibility of Clojure running on small embedded systems and other environments where the choice of underlying data structures and concurrency algorithms can't come baked in. This is mostly done already (as most things in Clojure are built on top of abstractions), but it still needs a deep look. - Open up the reader. A Lisp without full reader macros is unlikely to win over all potential converts, not because reader macros are this incredibly common thing, but because the personality of most Lisp hackers tends to thinking like "well I don't think I'll need a reader macro, but why would I want a language that won't even give me the option?"

hga 13y ago
Strong caveat about LLVM: it's not a good target for precise garbage collection, at a certain point the distinction between pointers and integers is lost. Fixing that would require diving into and writing a lot of C++, and I'd rather do that sort of work with a safe pointer language or drop all pretenses for the lowest level stuff.
- breckinloggins 13y ago
  I think a language like Clojure would have to go the ARC (Automatic Reference Counting, not the language) route. Whether that's even possible is another matter, but I agree that the LLVM memory management problem is an interesting one. Another question is whether there should exist a "sys lisp" that can form the lisp core of higher level lisps but that itself is not a garbage collected lisp. I don't immediately see a way forward on that one, but it's an interesting thought.
  - hga 13y ago
    For your last question you could start by looking at PreScheme: http://en.wikipedia.org/wiki/PreScheme http://en.wikipedia.org/wiki/PreScheme
    - breckinloggins 13y ago
      Thank you! This is a big missing piece for some of my research.
  - PuercoPop 13y ago
    >> Another question is whether there should exist a "sys lisp" that can form the lisp core of higher level lisps but that itself is not a garbage collected lisp... You may be interested in Henry Baker has a paper where he shows a VM where the semantics prevent garbage from being created http://home.pipeline.com/~hbaker1/LinearLisp.html http://home.pipeline.com/~hbaker1/LinearLisp.html
levosmetalo 13y ago
> - Open up the reader. A Lisp without full reader macros is unlikely to win over all potential converts, not because reader macros are this incredibly common thing, but because the personality of most Lisp hackers tends to thinking like "well I don't think I'll need a reader macro, but why would I want a language that won't even give me the option?" While I agree that most of the other points are valid personal opinions, this one could safely be ignored. New Clojure users are largely converted from the enormous Java, Scala, Ruby, ... developer pool, and ignoring the projected wishes of (Common) Lisp programmers is a valid choice.
reitzensteinm 13y ago
One interesting thing about having entirely immutable data structures is that you can allocate a temporary heap, and flip the GC around. Copy off just the result and junk the rest without looking at it. All without blocking the main thread. In certain circumstances - for instance a web framework creating a heap for each request - this will make GC dramatically cheaper. Though of course your cache locality will be poor.
- cynicalkane 13y ago
  This is a common practice in GC. For example, the JVM already does this by default, and you don't need to give it immutable data.
  - reitzensteinm 13y ago
    But immutability makes it conceptually a hell of lot cleaner, and feasible to do even if you're investing orders of magnitude less in your GC than went into the JVM. Which is important if Clojure gets ported to bare metal runtimes, as the parent was suggesting.
- lucian1900 13y ago
  That technique (commonly called semispace GC) works for mutable data as well, as long as you have a pointer indirection (so you can move), it's just less efficient than most others. It would be interesting to see whether the balance would shift significantly with immutable objects.
lucian1900 13y ago
For the native target, LLVM might not necessarily be the best choice. clojure-scheme [1] is an interesting approach, there might be some other suitable target that produces native executables as well. 1. https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme
rickjames28 13y ago
I doubt Rich Hickey is interested in those few remaining CL stalwarts that won't come over because he doesn't open up the reader. It's just a non issue.

hga 13y ago

Strong caveat about LLVM: it's not a good target for precise garbage collection, at a certain point the distinction between pointers and integers is lost. Fixing that would require diving into and writing a lot of C++, and I'd rather do that sort of work with a safe pointer language or drop all pretenses for the lowest level stuff.

breckinloggins 13y ago
I think a language like Clojure would have to go the ARC (Automatic Reference Counting, not the language) route. Whether that's even possible is another matter, but I agree that the LLVM memory management problem is an interesting one. Another question is whether there should exist a "sys lisp" that can form the lisp core of higher level lisps but that itself is not a garbage collected lisp. I don't immediately see a way forward on that one, but it's an interesting thought.
- hga 13y ago
  For your last question you could start by looking at PreScheme: http://en.wikipedia.org/wiki/PreScheme http://en.wikipedia.org/wiki/PreScheme
  - breckinloggins 13y ago
    Thank you! This is a big missing piece for some of my research.
- PuercoPop 13y ago
  >> Another question is whether there should exist a "sys lisp" that can form the lisp core of higher level lisps but that itself is not a garbage collected lisp... You may be interested in Henry Baker has a paper where he shows a VM where the semantics prevent garbage from being created http://home.pipeline.com/~hbaker1/LinearLisp.html http://home.pipeline.com/~hbaker1/LinearLisp.html

levosmetalo 13y ago

> - Open up the reader. A Lisp without full reader macros is unlikely to win over all potential converts, not because reader macros are this incredibly common thing, but because the personality of most Lisp hackers tends to thinking like "well I don't think I'll need a reader macro, but why would I want a language that won't even give me the option?" While I agree that most of the other points are valid personal opinions, this one could safely be ignored. New Clojure users are largely converted from the enormous Java, Scala, Ruby, ... developer pool, and ignoring the projected wishes of (Common) Lisp programmers is a valid choice.

reitzensteinm 13y ago

One interesting thing about having entirely immutable data structures is that you can allocate a temporary heap, and flip the GC around. Copy off just the result and junk the rest without looking at it. All without blocking the main thread. In certain circumstances - for instance a web framework creating a heap for each request - this will make GC dramatically cheaper. Though of course your cache locality will be poor.

cynicalkane 13y ago
This is a common practice in GC. For example, the JVM already does this by default, and you don't need to give it immutable data.
- reitzensteinm 13y ago
  But immutability makes it conceptually a hell of lot cleaner, and feasible to do even if you're investing orders of magnitude less in your GC than went into the JVM. Which is important if Clojure gets ported to bare metal runtimes, as the parent was suggesting.
lucian1900 13y ago
That technique (commonly called semispace GC) works for mutable data as well, as long as you have a pointer indirection (so you can move), it's just less efficient than most others. It would be interesting to see whether the balance would shift significantly with immutable objects.

lucian1900 13y ago

For the native target, LLVM might not necessarily be the best choice. clojure-scheme [1] is an interesting approach, there might be some other suitable target that produces native executables as well. 1. https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme

rickjames28 13y ago

I doubt Rich Hickey is interested in those few remaining CL stalwarts that won't come over because he doesn't open up the reader. It's just a non issue.