It should be pointed out that newLISP is an interpreted language with primary emphases on low memory usage, short start-up time, and efficient implementation. In that, newLISP is exceptionally successful; the amount of functionality that has been packed into an executable of just over 250 Kb is impressive. Automatic memory management is fast and simple and requires little overhead. In terms of speed, newLISP compares favorably to other interpreted languages (e.g. Perl and Python).

It also needs to be mentioned that newLISP is not Common Lisp. The name newLISP seems to indicate that newLISP modernizes and replaces Common Lisp. The FAQ on newLISP.org does take a decidedly populist tone with regard to other lisps. This is unfortunate, because newLISP is a very different language than CL or Scheme and is not truly in competition with them.

I’d like to discuss of a few of the more significant sticking points for potential users.

Macros

newLISP is a purely interpreted language. This has some important implications in its implementation. Macros are disimilar to compiled lisps. Most importantly, there is no compile-time expansion. All expansion is performed at runtime and with the overhead of a function all. In fact, newLISP macros are more like functions with lazy evaluation.

However, this does not completely diminish the power of newLISP macros. newLISP’s operator, letex, may be used to both expand and evaluate a block of code. Using the args function and implicit indexing, variable capture may be avoided in macros. Here is an extremely basic macro to iterate over the lines of a file using both letex and args:

(define-macro (dolines)
    (letex ((var (args 0 0))
                    (file (open (args 0 1) "read"))
                    (body (cons 'begin (rest (args)))))
        (while (set 'var (read-line file))
            body)
        (close file)))
 
(dolines (line "/path/to/file")
    (println line))

Variable capture

This is a real issue when writing newLISP. The function args can prevent capture by functions’ parameters, but there is no equivalent to Common Lisp’s gensym to dynamically create unique symbols. Fortunately, it is not difficult to write our own:

(define _gensym:_gensym)
 
(define (gensym:gensym (ctx MAIN))
    (if (_gensym (name ctx))
        (let ((new-sym (string "gensym-" (_gensym (name ctx) (+ 1 (_gensym (name ctx)))))))
                 (or (sym new-sym ctx) (gensym ctx)))
            (begin
                (_gensym (name ctx) 0)
                (gensym ctx))))

This demonstrates two other features of newLISP, contexts and dictionaries, which I will go into in more detail shortly. For now, it will suffice to explain that contexts are lexical namespaces (context symbols are typically denoted in the form context:symbol, similarly to CL packages) and dictionaries are a way to use contexts as an associative namespace.

Note that this implementation of gensym is dependent on the maximum integer value on the system. newLISP will wrap into negatives after the max integer, so the maximum number of symbols possible to create is generally twice the value of the max integer. However, symbols that have been deleted will be recycled.

Hash tables

newLISP does not use hash tables (see here for an explanation of why). This is a show-stopper for many. Without joining the (often heated) debate over this, newLISP does provide the same functionality as a hash through its dictionaries:

(define dict:dict) ; create the dictionary
(dict "foo" "bar") ; associates "foo" to "bar" in dict
(dict "foo") ; retrieves "foo" from dict

Or, programmatically:

(context dict "foo") ; => "bar"
(context dict "foo" "baz") ; sets foo:bar "baz"

Dynamic scope

newLISP is dynamically scoped. Because it is an interpreted language, much computation and memory is saved by avoiding the complexities of lexical scoping.

newLISP’s contexts do implement static scopes that can be used to create lexically enclosed modules and closures. Within the context, though, variable lookups are dynamic to the context. In the example above (gensym), _gensym is a context dictionary and gensym is a default functor (a function assigned to a symbol with the same name as its context is defined as a functor in newLISP). Within gensym:gensym, scope is dynamic to the gensym namespace, which is lexically isolated from the default namespace, labeled MAIN.

Garbage collection

newLISP uses a form of memory management called ORO (one reference only). From the newLISP documentation:

Memory management in newLISP does not rely on a garbage collection algorithm. Memory is not marked or reference-counted. Instead, a decision whether to delete a newly created memory object is made right after the memory object is created.

Empirical studies of LISP have shown that most LISP cells are not shared and so can be reclaimed during the evaluation process. Aside from some optimizations for primitives like set, define, and eval, newLISP deletes memory objects containing intermediate evaluation results once it reaches a higher evaluation level. newLISP does this by pushing a reference to each created memory object onto a result stack. When newLISP reaches a higher evaluation level, it removes the last evaluation result’s reference from the result stack and deletes the evaluation result’s memory object. This should not be confused with one-bit reference counting. ORO memory management does not set bits to mark objects as sticky.

newLISP follows a one reference only (ORO) rule. Every memory object not referenced by a symbol or context reference is obsolete once newLISP reaches a higher evaluation level during expression evaluation. Objects in newLISP (excluding symbols and contexts) are passed by value to other functions. As a result, each newLISP object only requires one reference.

The intuitive assumption is that this results in slow evaluation, but it does not. Nor is newLISP’s evaluation speed burdened by a garbage collector.

newLISP’s ORO rule forces newLISP to constantly allocate and then free LISP cells. newLISP optimizes this process by allocating large chunks of cell memory from the host operating system. newLISP will request LISP cells from a free cell list and then recycle those cells back into that list. As a result, only a few CPU instructions (pointer assignments) are needed to unlink a free cell or to re-insert a deleted cell.

The overall effect of ORO memory management is a faster evaluation time and a smaller memory and disk footprint than traditional interpreted LISP’s can offer. The lack of garbage collection in newLISP more than compensates for its high frequency of cell creation/deletion. Note that under error conditions, newLISP will employ a mark and sweep algorithm to free un-referenced cells.

Implicit indexing

Implicit indexing is syntactic sugar for indexed access to elements in a list:

(let ((lst '(1 2 3 4 5)))
    (lst 3))
=> 4

It also works for nested lists:

(let ((lst '(1 2 3 (4 5))))
    (lst 3 1))
=> 5

Prospective users often remark that this syntax breaks conventional semantics and makes it far more difficult to do meta-programming. The function nth exists in the language and may still be used for this purpose:

(let ((lst '(1 2 3 4 5)))
    (nth 3 lst))
=> 4

Concurrency and distributed computing

newLISP is not threaded. This in particular was a challenge for me. However, I have found that due to newLISP’s small size and quick start-up, forking new processes is quite painless. There are few programs where one would want to start hundreds or thousands of threads, and newLISP is able to launch a large number of processes in less space than a single instance of the Python interpreter.

Using the new Cilk-inspired API, concurrent programming is simple, cheap, and expressive. Additionally, there are few of the challenges associated with threaded programming.

newLISP also comes with built-in functions for distributed computing, permitting forms to be easily sent to other nodes over TCP/IP for evaluation:

(net-eval remote-server-ip expr-to-evaluate timeout response-handler)

Conclusion

newLISP packs a lot of power into its small size. Some of its more powerful built-in features include:

• a fast, simple concurrency API
• regular expressions (PCRE)
• native C library access
• XML parsing
• pattern matching
• HTTP networking
• sockets
• cross platform GUI server (using Java)
• bayesian training and probability analysis
• cross platform support – newLISP uses only standard libraries

newLISP does not deserve the pariah status to which many relegate it. While newLISP cannot replace a compiled language for the most intensive tasks, it remains a fun, artful language and is excellent for exploratory programming and rapid prototyping, while remaining fast and powerful enough for the final product.

Submit article

There are several slime profiling functions, but the simplest is slime-profile-package (M-x slime-profile-package), which profiles all functions in a package. You will be asked for the package name to profile. All functions in the package will be profiled. slime-profile-functions gives you more control over which functions to profile. The profiling of a single function can be controlled with slime-toggle-profile-fdefinition.

After entering the package name, you are asked whether to record the most common callers and whether to profile methods as well as typical functions. To view the results, you use slime-profile-report, which displays a table of the most commonly called functions, time spent in each, amount of consing in each, calls, total time, etc.

Before the next run, be sure to use M-x slime-profile-reset to reset the profiling statistics so you get a fresh and accurate report.

Optimizing functions

Generally, you should attempt to write a more efficient algorithm before depending on compiler optimization declarations. The slime profiler will tell you which functions are taking the majority of your application’s time, and making these more efficient will serve you better than tuning the manner in which a function is compiled. However, once your function is written to your satisfaction, you may wish to further tune it by sacrificing speed for lower memory usage (or vice versa) or trading debug information for extra speed.

Lisp compilers accept a few optimization declarations that can earn you significant speed-ups. The compiler generally optimizes code based on four variables: speed, safety, debug, and compilation-speed. These can be set between 0 and 3 with a declaration:

(defun foo ()
     (declare (optimize (speed 2)
                        (safety 3)
                        (debug 3)
                        (compilation-speed 0)))
     (format t "~&Hello world~%"))

Generally, lowering the debug value of a function makes trouble-shooting your application extremely difficult. For example, the name of the function may disappear from backtraces. Therefore, lowering this value is usually only worthwhile once the program has been suitably tested and deployed. Use the profiler to determine which portions of your code will provide the most benefit.

Macros and optimization

Macros are sometimes touted as a way to optimize code. In a compiled lisp program, they can cause some calculations and expansions to be performed at compile time, saving run-time. In situations where much of the information is known ahead of time, this can be an effective technique, although overuse can be dangerous. For example, rewriting a function as a macro will make debugging more difficult, since the macro is expanded in the compiled code. A problem in a macro may only be shown as a problem in the function that utilizes the macro.

Note that in interpreted lisps, especially those without any form of compilation (such as newLISP), macros provide no speed-up. In fact, in newLISP, macros are just functions that do not evaluate their arguments.

More info

slime profiling documentation

Submit article

from models import Person
person = Person.objects.get_or_create(first_name="John", last_name="Johnson")

It adds syntactic sugar to the common case of checking if an entry exists, creating it if it does not, then updating (or creating with new) values. The problem is that its slow.

I offload our most expensive database work on our server to a Lisp-based XML RPC server using CLSQL. I wrote an analog of get_or_create for CLSQL. It does not have the advantage of Django’s keyword searches; all searches use = and pull the first row that matches the value.

The first function, get-instance is a helper to get a row in a view-class using a field/value pair.
create/update takes the first three arguments and passes them to get-instance to get any existing match.

(defun get-instance (cls pk val)
  #.(clsql:locally-enable-sql-reader-syntax)
  (let ((inst (clsql:select cls :flatp t :refresh t :limit 1
                            :where [= (clsql:sql-expression :attribute pk) val])))
    #.(clsql:restore-sql-reader-syntax-state)
    (if inst (car inst) nil)))
 
(defun create/update (cls pk val &rest args)
  (let ((inst (get-instance cls pk val)))
        (if inst
            (apply #'reinitialize-instance inst args)
            (apply #'make-instance cls pk val args))))

Usage:

(clsql:def-view-class person ()
    ((id
        :reader person-id
        :db-kind :key
        :db-constraints :not-null
        :type integer
        :initarg :id)
    (last-name
        :accessor person-last-name
        :db-constraints :not-null
        :type (clsql:varchar 25)
        :initarg :last-name)
    (first-name
        :accessor person-first-name
        :db-constraints :not-null
        :type (clsql:varchar 25)
        :initarg :first-name)))
 
(defvar john (create/update 'person :id 3))

If there is row with id 3 in the database, it will grab that (or, if the key is not unique, it will grab the first matching row.) If there is no entry with that id, it will create a new one, that can then be updated the normal way:

(setf (person-last-name john) "John")
(setf (person-first-name john) "Johnson")

The other alternative is to get and set all in one go:

(defvar john (create/update 'person
                            :id 3
                            :last-name "Johnson"
                            :first-name "John"))

It’s pretty simple but it is very useful.

Submit article

Common Lisp’s destructuring-bind uses unification to bind local variables, much like let. Given a list of arbitrary depth, destructuring-bind can “extract” its elements and bind them in a lexical block.

(setf lst '("foo" "bar" ("baz" "bat")))
(destructuring-bind (a b c) lst
    (format t "~A, ~A, and ~A" a b c))
; => foo, bar, and (baz bat)

newLISP has a unification function and a bind function that can do much the same thing.

(set 'lst '("foo" "bar" ("baz" "bat")))
(bind (unify '(A B C) lst))
(println A ", " B ", and " C)
; => foo, bar, and ("baz" "bat")

Unfortunately, attempting to use a unification in a local scope does not work so easily:

(let (unify '("foo" "bar" ("baz" "bat")))
    (println A ", " B ", and " C))
; => symbol is protected in function let : unify

This can be worked around with a macro and letex, which provides similar functionality to Common Lisp’s macro template syntax (except that it uses quoted, locally bound symbols, rather than backticks to insert values):

(define-macro (destructuring-bind)
  (letex ((unifier (args 0))
          (target (args 1))
          (body (rest (rest (args)))))
    (let unifier
      (bind (unify 'unifier 'target))
      (dolist (expr 'body)
        (eval expr)))))

This is a reasonable approximation of the CL destructuring-bind macro, although don’t try and pass (args) directly to it (this is a limitation of macros in newLISP; (args) would evaluate to a list of destructuring-macro‘s arguments, not the calling function’s.

This implementation locally initializes the variables to be unified to nil and then binds them to the result of unify. Once bound, it iterates over the expressions in the body of the form.

cond can be used to match against various patterns of arguments passed to a function:

(define (foo)
    (cond
        ((unify '(A B C) (args)) (do something))
        ((unify '(A B) (args)) (do something else))))

This makes routing of different arities possible, but not convenient. With a couple of macros, we can go a step further and create a destructuring-case conditional that accepts the target list for unification and a series of conditionals, as with cond:

(define-macro (cond-form)
  (letex ((target (eval (args 0)))
          (unifier (nth 0 (eval (args 1))))
          (body (nth 1 (eval (args 1)))))
         '((unify 'unifier 'target)
            (destructuring-bind unifier target
              body))))
 
(define-macro (destructuring-case)
  (letex ((target (first (args))) (conditions (rest (args))))
         (eval (cons cond (map (fn (c) (cond-form target c))
                               'conditions)))))
 
(set 'lst '("foo" "bar" ("baz" "bat")))
(destructuring-case lst
  ((A B C) (println A ", " B ", and " C))
  ((A B) (println A " and " B))
  ((A) (println A)))
 
; => foo, bar, and ("baz" "bat")

Although this does not permit a function to be defined multiple times in terms of its arity, it does enable equivalent functionality, albeit within the function body:

(define (test)
  (let ((params (args)))
    (destructuring-case params
      ((A B C) (println "Case 1: " A ", " B ", and " C))
      ((A B) (println "Case 2: " A " and " B))
      ((A) (println "Case 3: " A)))))
 
(test "foo" "bar" '("baz" "bat"))
; => foo, bar, and ("baz" "bat")

Links:

• unification
• unify (newLISP)
• destructuring-bind

Submit article

Before that can be done, however, a note for those who do not know C. Functions in C have a declared type, as do all of their arguments. When reading the docs for a particular library, you will want to know description conventions for C routines. Let’s use the example of mysql_init() to begin with.

MYSQL *mysql_init(MYSQL *mysql)

The first part, MYSQL *mysql_init, defines the function’s return type and name. MYSQL is a type created by the library that stores a struct. This is actually completely irrelevant at this point, because of the asterisk. The asterisk means that the function is actually allocating a pointer. Although we can pass an already existing MYSQL object pointer (that’s the second part), generally we will just use this function to create the internal struct needed to run the program. We will need to store the pointer that is returned.

The second part, MYSQL *mysql, states this- namely, that a pointer (named mysql, and we know it’s a pointer because it’s labelled with an asterisk- *mysql) will be returned. We store it because this will be passed to most of the other routines in the library.

Technically, we do not really need to define the routine in Lisp. The function, foreign-funcall, allows us to call the foreign function directly.

(foreign-funcall "mysql_init" :pointer (null-pointer) :pointer)

In this, we apply mysql_init to a null pointer (an empty pointer argument), created using the CFFI function (null-pointer). The last symbol states we will get a pointer back.

In order to wrap this as a pretty Lisp function, we do:

(defcfun ("mysql_init" libmysql-init) :pointer
  (mysql :pointer))

This points the Lisp symbol libmysql-init to “mysql_init” in the C library. The next argument, :pointer, states that this returns a pointer. Next, we can have an &rest list of (parameter-name :type), to define the parameters to pass to the function, in this case, (mysql :pointer). Available types are listed in the CFFI documentation.

However, we don’t want to have to run (null-pointer) every time we use this function. We also need to store the return value for future use. So let’s wrap it in another function to make it more expressive:

(defun mysql-init ()
  (setq *mysql* (libmysql-init (null-pointer)))
  (or *mysql* (setq *mysql* nil)))

Now, we can simply run (mysql-init) and we will have the symbol *mysql* pointing to the returned pointer or nil in the event of a failure.

If we do have a failure, we can use the following definitions to get at the error text:

(defcfun ("mysql_error" libmysql-error) :string
    (mysql :pointer))
 
(defun mysql-error ()
    (libmysql-error *mysql*))

Of course, we will want to add error handling and some other niceties, but having these declared makes writing and testing those completed functions that much easier.

Submit article

My database of choice (and the one available to me on my host) is MySQL. Unfortunately, this is the piece of CLSQL that I can’t seem to get running on OSX. In every dialect I’ve tried (sbcl, cmucl, clisp, openmcl, ad infinitum), CFFI/UFFI cannot find the libmysqlclient library- even when it has been pushed onto the library search path… but that is a rant for a different blog (or Usenet).

CFFI is generally available via ASDF and plays well with GNU CLISP. It has a fairly simple, intuitive syntax for making C routines available to lisp (as a side note, I have not encountered anything as easy as newLisp’s C library importer, although this is made easier in that newLisp is implemented in C).

Using CFFI, we can fairly easily create mappings for the most important MySQL C api functions. This entry will walk through the process of importing the library; future entries will go one to defining a few of the most basic routines for our lisp image.

Let’s begin by defining our mysql wrapper package.

(defpackage :mysql-api
  (:use :common-lisp :cffi))
(in-package :mysql-api)

To load the library itself, we use the function, define-foreign-library, in the CFFI package. The first argument to define-foreign-library is the symbol we wish to point to the library. Next, we create list similar in syntax to cond, where we define the names of our libraries based on, for example, the host OS. Since I happen to know that CFFI does find the library path even when explicitly specified, we can conveniently specify a list of full paths to try for each OS. The full list of platform symbols available here.

(define-foreign-library libmysqlclient
  (:darwin (:or "/usr/local/mysql/lib/libmysqlclient.dylib"
                "/sw/lib/libmysqlclient.dylib"
                "/usr/local/lib/libmysqlclient.dylib"))
  (t (:default "libmysqlclient")))

The last line is a catch-all, and will format the filename based on the OS (i.e., libmysqlclient.so for unix, .dll for Windows). Although I know my library is located in /usr/local/mysql/lib, I have included various other commonly used paths for MySQL libraries in OSX.

Then, to load the library:

(use-foreign-library libmysqlclient)

This will return a pointer to a foreign address (for the C-challenged, a pointer is a variable to points to a value’s address in memory; it is used to access a value by reference, rather than by value) or, in the event that it did not work, it will throw up an error. Generally, the error will be caused by CFFI not being able to find the library. If this is the case, verify that your account has access to the file and that the file is included in one of the paths above.

Next, we will begin defining our C routines in lisp.

Submit article

This has also kept many imperative languages moving forward. Python may be the most lispy, but there is also Ruby, which conceptually borrows heavily from languages like lisp and Smalltalk. Even Javascript has lambda functions (although in JS they are called function literals), which has made possible powerful libraries such as Prototype.

Few lisps have ever borrowed from imperative languages, though, as if the borrowers have absolutely nothing to offer themselves. A few concepts have made it in. OOP, via CLOS, although OOP is often just extra weight in lisp. Storing functions as data makes much of OOP needless in lisp.

newLisp, a dialect of lisp that uses s-expressions in a high level, interpreted language, has borrowed from imperative languages, and has done an excellent job of maintaining its lispy character despite it. Regex is built into the interpreter and is used in many functions:

(regexp {brown fox$} "the quick brown fox")
(replace {brown fox$} "the quick brown fox" (upper-case $1))

Iterative control structures are built into the interpreter, rather than be implemented through macros. Common Lisp’s LOOP is very powerful but not very idiomatic of lisp and not very elegant to use (in fact, many of those involved in the original development of the language did not like LOOP, feeling that it was not lispy enough). In newLisp, iterators definitely have a lispy feel to them:

(dotimes (i 10) (println i))
(dolist (n '(foo bar baz bat)) (println n))

Other similar looping functions in newLisp are dolist, doargs, and dotree. There are also while, until, unless, and do functions, which all work about as you would imagine in a lisp.

No language will survive in a pure form. Concepts may – s-expressions and lists – but lisp must be willing to evolve on a larger scale. Lisp was built to evolve, so it’s a shame that so few of the people who continue to plough ahead in the language want it to.

Submit article

In short, a macro is a type of function that allows the programmer to define new syntax for use in their programs. For example, I often hear Rubyists decry the lack of code blocks and Enumerable in other languages. So, let’s create a macro called “each” and bring this functionality to newLisp.

In Ruby, iteration is performed using the “each” method on an object. Let’s say we have the list, ["one", "two", "three"]. We want to print out “I can count to x” for each item in the list. We might use:

["one", "two", "three"].each do |x|
  puts "I can count to #{x}."
end

While there are many ways to do this already in newLisp, such as:

(map (lambda (x) (println "I can count to " x))
  ("one" "two" "three"))

…let’s see how to extend our syntax so we can write this as we would in Ruby. Macro syntax works almost exactly as it would in a regular function. The big difference, though, is that arguments passed to your macro are not evaluated. When you run (foo bar) in lisp, foo is applied to the value of bar. With a macro, the symbol bar itself is passed, rather than its value, and the macro must evaluate the symbol to its value manually.

(define-macro (each object do iter)
  (set 'iter (trim (string iter) "|"))
  (dolist (obj (eval object))
          (eval (set (sym (eval iter)) obj))
    (doargs (a) (unless (= a 'end) (eval a)))))

Let’s see what’s going on here. Our macro, each, accepts three argument: object, do, and iter. Object refers to the object over which we wish to iterate. Do is a placeholder for the “do” in the each syntax. Iter is the pipe-encased variable name which we will iterate over.

(set 'iter (trim (string iter) "|"))

The first thing we do is trim off the pipe characters to get the variable symbol.

Next, we use a newLisp iterator, dolist, to iterate over object. Notice that here we must evaluate object so that we are working with the list itself.

Inside our dolist, we assign obj to the symbolic representation of iter, (sym iter). In our example above, this is the same as saying (set ‘x obj). Now we can access each member of the list, object, using the symbol ‘x.

Next, we use the doargs function to iterate over the remaining arguments (in newLisp, all arguments not specified in the function definition are available through the command args, and are iterable using doargs). The unless statement checks for and ‘end symbol. If the argument is not ‘end, it evaluates it, subbing in obj for x.

Careful readers will note that if there are commands after ‘end, they will be executed for a given value of x as well, but hey, it’s a blog entry, and we aren’t writing a Ruby interpreter :).

Now, the final product is:

(each '("one" "two" "three") do |x|
  (println "I can count to " x)
end)

Which will print:

I can count to one
I can count to two
I can count to three

Submit article

A brief explanation of the lisp distribution

Lisp began in the fifties and was the cool new thing. After a few years, new features were needed, and by this time, there were already several groups that had written interpreters for the language (lisp is both an interpreted language, like Perl, and a compiled language). Each had added features to the language in different ways. Various groups got together to standardize the language. This was a good thing at the time because it brought together all of those differences into one standard. However, once a language is standardized by a large committee, it becomes that much more difficult to update it, especially if it means straying from the standards. Lisp often gets around this because it has macros, which are functions that can create new syntaxes for the language.

The standard was called common lisp, and is supported by most major distributions of lisp. There are other, lisp-like languages from before the standard, such as Scheme, that survived outside the standard because they were already well-established.

Other distributions, such as SBCL, MCL, Gnu, Allegro, et al., support the common lisp standard. Each, however, has extras that come with them. Think of them the same way you would think about Linux distros; each supports a basic core functionality, but some specialize in certain areas and have extra libraries and built-in functionality that express this. For example, MCL is built for Macs, and has the ability to work in tandem with AppleScript and Apple’s windowing libraries. I originally chose Gnu clisp because it had built in regex functions, whereas many other lisps require that you install a 3rd party library to support regex (and installing 3rd party libraries is a semester-long course in itself).

How to learn lisp

There are dozens of tutorials online that you could start with. Hundreds, probably. The problem is that lisp was designed when software was written by engineers and scientists; there was no such thing as the hobbyist. Most online tutorials use scientific or mathematic examples that not everyone is familiar with. I myself have a degree in Spanish; most of the examples were pretty meaningless to me.

I found the online book, Practical Common Lisp, which was helpful, but still a little above my head in some areas. It jumps around a lot and is really for the established lisp programmer who wants to see how another advanced lisp programmer would ineffectively explain lisp to a rookie.

The best instruction I found was a book called, Common Lisp: A Gentle Introduction to Symbolic Computation. It’s dumbed down pretty far, but because lisp is so different from other languages, it really is worth your time to go through the book to understand the concepts. After that, online tutorials will make some sense and you will have a good foundation from which you can build. At the very least, you won’t be confused when you see something like (eq (+ 2 2) 4).

Enter newLISP

If this is all a bit much for you and you just want a taste, give newLisp a look. It uses the same syntactic conventions as lisp, but it has a modern set of functions and is a completely interpreted scripting language, like Perl or Python. Even if, as with me, you decide to stick with newLisp over other lisps, A Gentle Introduction will still benefit you immensely (even if you don’t stick with lisp at all, the book will make you a better programmer).

Submit article