I would love to see announcements of new languages include a rationale. Why was this created? What problem was the author trying to solve that they thought the solution was a new language? What short comings did existing languages have that this new language overcomes?<p>This is not a critique; I'm just curious.
Oh hey, I posted this on /r/lisp just earlier today. I discovered it because of a Google rabbit hole triggered by a rediscovery of this article[0] on Naughty Dog's GOAL (Game-Oriented Assembly Lisp). It looks really interesting, although I can't imagine doing serious programming in it (as much as I'd love to).<p>[0]: <a href="http://www.codersnotes.com/notes/disassembling-jak/" rel="nofollow">http://www.codersnotes.com/notes/disassembling-jak/</a>
Very neat! Looks like this is an even older language than the one I'm familiar with: bone-lisp. Bone-lisp is interpreted but ops for "explicit regions instead of garbage collection". There is also an awesome list of similar projects on the bone-lisp README (on which I now see Dale included) which I'll quote from:<p>> Somewhat related Free Software projects:<p>> * Pre-Scheme is a GC-free (LIFO) subset of Scheme<p>> * Carp is "a statically typed lisp, without a GC"<p>> * newLISP uses "One Reference Only" memory management<p>> * MLKit uses region inference (and a GC)<p>> * Linear Lisp produces no garbage<p>> * Dale is basically C in S-Exprs (but with macros)<p>> * ThinLisp is a subset of Common Lisp that can be used without GC<p>[1] <a href="https://github.com/wolfgangj/bone-lisp" rel="nofollow">https://github.com/wolfgangj/bone-lisp</a>
At a glance, the compiler looks solid, with full LLVM integration instead of compiling to C. That'll pay dividends down the road. Really great job :)
This looks really nice. A low level Lisp as a system programming language - a C replacement - is an interesting idea. First thought after going through the readme: does it try to provide stable ABI? This is an important feature for a C replacement; for example, C++ has not managed to get it right, although the idea was to provide a better, object oriented C... What worries me in particular is that Dale has overloaded functions, that makes things harder as far as stable API is concerned, but maybe I'm wrong. Nice stuff, anyway. I can see a little PLT trend of new high level languages that want to be good in doing low level stuff and don't use GC. I like that!
A systems programming language need not eschew GC. Zetalisp and Common Lisp are perfectly fine for Lisp Machine operating system implementation, without falling back to a language other than assembly for isolated bits of the very lowest-level code. Mezzano reaffirms this on x86-64 too.
Another Lisp implemented in C++, but with a GC:<p><a href="https://github.com/rongarret/Ciel/" rel="nofollow">https://github.com/rongarret/Ciel/</a>
isn't this a C-flavored lisp?<p>I mean, it's <i>not</i> C. And it <i>is</i> a lisp.<p>So doesn't it make sense to call it "lisp with a flavor of C" rather than the other way around?<p>Cool project!
Any high-order functions, TCO? Is there an implementation of <i>Everything Is An Expression</i> and <i>Everything Is A First-class Value</i> principles? Type-tagging, which implements <i>Values Has A Type, Not Variables</i> principle, which gives <i>The Numerical Tower</i> and other nice things for free? Proper lexical scoping based on Environments which makes every lambda a closure? I am not asking about homogeneity and the possibility of the <i>First-class Macros</i> it provides.<p>No? So what then makes it Lisp-flavored? CONS CAR CDR and parentheses?
C's syntax is horrible, but we can live with it. Where are the attempts to fix C's semantics, dammit? This project is as if a mechanic were given a broken car, and the first thing he did were repainting it.
Why isn't it written in Lisp? It would be so much easier...<p>See for example C-MERA:<p><a href="https://github.com/kiselgra/c-mera" rel="nofollow">https://github.com/kiselgra/c-mera</a>