Urn is a new language developed by SquidDev, and demhydraz. Urn is a Lisp dialect with a focus on minimalism which compiles to Lua.
- A minimal¹ Lisp implementation, with full support for compile time code execution and macros.
- Support for Lua 5.1, 5.2 and 5.3. Should also work with LuaJIT.
- Lisp-1 scoping rules (functions and data share the same namespace).
- Influenced by a whole range of Lisp implementations, including Common Lisp and Clojure.
- Produces standalone, optimised Lua files: no dependencies on a standard library.
¹: Minimalism is an implementation detail.
What is McCLIM?
McCLIM is a FOSS implementation of the Common Lisp Interface Manager specification, a powerful toolkit for writing GUIs in Common Lisp. It is licensed under the GNU Library General Public License.
You can access the McCLIM manual draft PDF if you want, but it’s still a work in progress. To reach the developers you may either write to the mailing list or on the #clim irc channel.
- Mature yet modern CLIM II protocol implementation
- Extensible GUI toolkit for applications
- Sophisticated interface manager for Common Lisp
- Portable between various Common Lisp implementations
- Robust solution for creating end-user applications
Some external tutorials for CLIM may be found here:
One of the key problems in onboarding developers to use modern Common Lisp is the vertical wall of difficulty. Things that are routinely problematic:
- emacs use. Most people don’t use emacs.
- Library creation. Putting together ASDF libraries and using them is a fairly horrid experience the first time.
- Selection of Lisp implementation to use, along with an up-to-date discussion of pros and cons.
- Putting together serious projects is not commonly discussed.
This site is dedicated to handling these problems. My goal is to put together an introduction/tutorial for practicing professionals and hobbyists from other languages. People who want to get started with Lisp beyond just typing into a REPL. Right now, it feels like this information is less disseminated and much less centralized than it otherwise might be. It’s not intended to be a HOWTO for Common Lisp. That’s been covered quite well. But it is intended to be a HOWTO on how to put together a Lisp environment.
Anyway, I’d like to collaborate with other people to make this a remarkably fine Lisp help site. Contributions are both accepted and welcome. It’s a wholly static site at this point in time – I don’t see a need for articulate-lisp.com to have a dynamic backend. Perhaps/probably one of the code examples will be a webapp.
P.S.: feel free to contact me for anything you like.
Lisp is a deep language with many unusual and powerful features. The goal of this tutorial is not to teach you many of those powerful features: rather it’s to teach you just enough of Lisp that you can get up and coding quickly if you have a previous background in a procedural language such as C or Java.
Notably this tutorial does not teach macros, CLOS, the condition system, much about packages and symbols, or very much I/O.
Clojure is a dialect of the Lisp programming language created by Rich Hickey [Clojure]. According to Wikipedia, Mr. Hickey created Clojure “because he wanted a modern Lisp for functional programming, symbiotic with the established Java platform, and designed for concurrency.” [Clojure]. Since then, Clojure has gathered somewhat of a following in the functional programming community, the other chief contender for functional programming on the JVM being the Scala programming language. This blog will attempt to document my quest to achieve two of Mr. Hickey’s goals using straight-up Common Lisp: idiomatic functional programming & concurrency. Why am I doing this? I tried Clojure and was disheartened by two aspects of the language: lackluster performance and the constant resurfacing of the Java and the JVM in error messages and other aspects of working with Clojure. I know of ClojureScript and the ability to run it on Google V8, but I suppose I really wanted a non-hosted language where I can intuitively map abstractions to assembler code by calling something like (disassemble … ) on a simple function. I tried Scala and missed homoiconic macros. Somehow I could not shake the feeling that homoiconic macros were intimately tied to the very essence of functional programming. I was also puzzled by the suggestion that Lisp, in its current form, somehow lacked modernity. Popularity, yes, modernity I wasn’t sure of… We will add one twist to the story. With Lisp being a programmable programming language, I can surely re-engineer any design goals of Clojure using Common Lisp by way of macros — but the challenge here is to do without such an effort. Therefore there are two rules in this game: 1) I am not allowed to write the keyword “defmacro” 2) I must rely on stock libraries / frameworks. “Stock” will be defined as installable via Common Lisp’s package manager Quicklisp [QuickLisp]. The “long and short of it is” that I want the utility of Clojure with the performance of Common Lisp. As Dough Hoyte points out in the book Let Over Lambda [Let-Over-Lambda], Lisp is not precisely a functional programming language, not in the the sense that Haskell and ML are functional programming language. I aim to challenge that. In https://chriskohlhepp.wordpress.com/convergence-of-modern-cplusplus-and-lisp/ [Lisp-Converge-C++] we showed how to bring Lisp close to C in performance by matching the generated Assembler code. In this blog we aim to “bring Lisp in line” with idiomatic functional programming concepts. With our two rules in mind, let us see how far we can travel on this road…