Tag Archives: lisp

Vomit

You bloated oaf, gorging on galaxies of glut. Go away. You and your UML, your pathetic paradigm. “Object-oriented!” you cry, diverted from the devastation of your application. Failing to find the chink in the armor, the aroma of smoke unsettles your strategy. “Scalability! We’ll scale the scales!” Disillusioned with lubrication by refactoring, factories, actors, event driven development. Drizzles of gristle. Is programming still fun? Functional, formulae conjunctional, cool, casual, actual work done. For fear not the lambda, the greek grapheme of ephemeral memorable purpose. Pose the function as transformer, reformer of data from input to output to input to output to input. Slews of loops, looping the function again. Again. Again. Break! How can you construct a deductive mechanism for deducing data from consumable samples, if not in Lisp? Or if not that, in OCaml? Oh come on, there’s loads of lovely ladies carrying coy caricatures of lisps, little lilting voices, smut for the C-smitten. Crackers to your brackets, but barely a soul seeks murky, mechanical LISP. Lots of irritating superfluous parentheses? No. “ML.” A moan, a mouthful of semantically laden syllabic syntax. The rub: Ruby, used usually in the uncool procedural sense, incidentally features the little fucker. Lambda, you dog! Ruby dooby do! Python’s on the list, Lua not excused, it’s there too. Odds are, philistine, your tool of choice has lambda in its toolkit, so zarking use it. If you suddenly saw the earth beneath your eyes realizing you could fly, would you reduce yourself to the banality of walking? Wake up. Procedural programming is impoverished. Appreciate artificial intelligence, barely a leap for lisp gents, or more generally, lisperati. Objects are unnecessary. Data defined by fiat, ha! Data’s declared by necessity, flowing from the form of the transformation: Integral to a collection of cows coldly calculating calculus to reality. Really. If the function makes steak, grant not anything but boves. There’s your objective. Objects are trash, nasty, thrashing not solving but revolving on nonproblems of encapsulation. Try algebraic data types on for size. As a small consolation, consult the folks who gave the gravy, namely garbage collection; remember, Lisp invented it. If not for Lisp, then conditionals wouldn’t be. B being C’s predecessor, son of BCPL, son of CPL, son of ALGOL, son of FORTRAN, son of assembly. That’s a long line and a lot of time to wait for the second coming of the lambda calculus, Church’s research not crucified but sadly set aside. Sigh, sheer boredom with annoying von Neumann machines must have been McCarthy miraculous leap to Lisp. The future is functional, finally. And it’s stuck in 1960 where real work, not XML, was done. The past is Prolog; the rest formatting, an exercise for the writer.

Prefix, Postfix, Newfix, Bluefix

My, my, look at all those notations. You can infix: 2 + 2. You can prefix: + 2 2. You can postfix: 2 2 +. All three notations are perfectly arbitrary for the purposes of mathematics. (2 + 2) * 3 = 12, so what’s really different about these codes?

Code 1

x = 2 + 2
y = x * 3
print(y)

Code 2

x := 2 plus: 2
y := x times: 3
y print

Code 3

2 2 + 3 * print

Code 4

(let* (
   (x (+ 2 2))
   (y (* x 3)))
      (print y))

Code 1 is typical of procedural programming (Python1, C, Basic, Pascal). You declare variables, store data in variables, and display variables.

Code 2 is typical of object oriented programming (Java, C++, Ruby2, Smalltalk2). You instantiate objects, send messages to objects, and display objects.

Code 3 is typical of stack programming (Factor, Joy, Forth). You push values onto the stack, push functions onto the stack, and display the stack.

Code 4 is typical of functional programming (Haskell, ML, Erlang, Lisp). You pass expressions, evaluate expressions, and display expressions.

But what’s really different?

Codes 1 and 2 are fundamentally the same: they’re stateful computations. Code 1 stores state in variables, Code 2 stores state in objects, but it’s all the same. Code 2 is syntactical sugar for Code 1. And Code 1 is syntactical sugar for:

Code 0

add x,2,2
mul y,x,3
put y

In other words, you’re still explicitly performing register transactions. Do this calculation then STORE THE RESULT IN HERE. Do that calculation then MOVE THE BYTES TO THERE.

By contrast, Codes 3 and 4 are an island all their own: they’re functional computations. Instead of manipulating machine registers, they manipulate mathematical expressions3. Code becomes data becomes code again; you can pass functions as arguments to other functions as if they were pure mathematical constructs. Code 4 named the expressions “x” and “y”, while Code 3 didn’t, but as Code 3 shows, naming isn’t really necessary, it’s just a convenience.

So what’s really different? Functional programming provides a whole new level of abstraction, one that allows you to write more complex code than you could in low-level languages like Java. Really. Do you like moving bytes around, or would you prefer to leave that as an exercise for the compiler?

1 Python has functional elements, but they’re underused. Most Python programmers aren’t even aware that Python has list comprehensions and anonymous functions.

2 Ditto for Ruby and Smalltalk. They have blocks, and therefore can do functional programming, but it’s not emphasized. With all the OOP hullabaloo, the incentive is to write stateful methods instead of pure methods, especially in Ruby where the line between f and f! blurs because the result of the last evaluated expression is always returned.

3 Most functional languages have stateful capabilities, but they’re strictly only necessary for specialized calculations such as pseudo-random number generation, concurrent programming, and I/O. Also, functional language compilers must be stateful in order to compile functional programs that provide the abstraction of pure, stateless code. (see Haskell).

Chicken Scheme for the Soul

chicken scheme logoRemember the child-like glee of writing your first computer program? It’s damned hard, but also fun. You feel in control, the god of a tiny universe. Anything is possible! But as you’ve matured, your smile may have faded. Programs are no longer for enjoyment, but for verification. Design, unit test, implement, commit, doze, repeat. Has programming become a bore? It’s time to rekindle the fire.

If you haven’t learned Lisp yet, it’s highly recommended. Don’t worry that your boss still wants you to use Java. Don’t worry that it feels… alien. When it finally clicks, you’ll learn to program as you never have before, and you can take that knowledge back into the corporate, very much non-functional world. You can return to the barren moor of C# armed with Lispy methodology in a .NET environment.

There isn’t just one Lisp. There are lots and lots and lots of Lisps, and it’s hard for a newbie to decide between them. For now, we’ll introduce you to a friendly little hen called Chicken Scheme. It’s a language with round corners, a relaxed type system, and a focus on practical programming.

How practical? Chicken Scheme comes with both an interpreter (csi) and a compiler (csc). If you prefer one tool or the other, it’s perfectly fine to use just that. Or, you can test your code with csi and compile your finished projects with csc. But do try the interpreter at least once; it could change the way you program.

Installing Chicken Scheme is fairly easy. Macs use MacPorts.

sudo port install chicken

Linux uses the package manager of your choice.

sudo apt-get install chicken

.
Windows uses the chicken-iup installer.

It’s time to have some fun! Fire up the interpreter by opening a terminal and entering csi.

$ csi
CHICKEN
(c)2008-2011 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.7.0
#;1>

Chicken can add numbers.

> (+ 2 2)
4

Chicken can reverse lists.

> (reverse (list 1 2 3))
(3 2 1)

Chicken can test list elements for evenness.

> (map even? (list 1 2 3))
(#f #t #f)

Chicken can test list elements for <PROPERTY-OF-YOUR-CHOICE>.

> (map (lambda (element) (* element 2)) (list 1 2 3))
(2 4 6)

If you can learn to write lambdas, you’re well on your way to becoming a first-class functional programmer!

Starting to get the hang of it? Play around, don’t limit yourself to the code in a tutorial. It doesn’t take long to program something big and practical like a unit test framework (~ a day).

If you’re lost, login to Freenode IRC join the #chicken room. The folks there are friendly, competent, and hilarious. Finally, if you find Chicken Scheme isn’t doing what you want it to do, you can customize it. Sometimes all you need to be happy is a little ~/.csirc config file :)

top: The poor man’s performance analyzer

hunchentoot logoFor the sake of the future of all mankind, I wrote a tiny web server for proving that Hunchentoot works with certain system specs. “doeshunchentootwork” is only 77 lines long, serves a singe page and its favicon, and the application is compiled, not interpreted. So why does top show it using so many CPU cycles?

Daemonization may have been a bad idea, at least this early in development. The process spends a lot of time… doing what exactly?

Since the app is only 77 lines long, debugging wasn’t that hard. Long story short, CL loads the program and quits, so I was using (loop) to keep the program running. I know, I know, terrible. (read) is a better choice, since it doesn’t waste CPU by looping but merely blocks for command line input that will never arrive to a daemonized web server.

With the new code, top shows almost no activity for doeshunchentootwork unless someone is currently requesting the webpage. Whew! Now the resources can be wasted on other servers.

I just want Hunchentoot!

hunchentoot logoThere’s something to be said for tutorials like Lisp for the Web. Adam Peterson’s guide to the Hunchentoot web server is easy and fun. Trouble is, gathering equipment is difficult.

Setup should be relatively simple. Equipment needed: Common Lisp, Quicklisp, and Hunchentoot.

  1. Pick your Common Lisp: SBCL, CLISP, ECL, ABCL, CCL, LispWorks, AllegroCL, XCL, WCL, CMUCL, GCL, etc.
  2. Install Quicklisp.
  3. Run (ql:quickload "hunchentoot").
  4. Run (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)).

Depending on which operating system you have and which Common Lisp you used, you’ll get different errors when you follow those instructions.

Trouble is, getting a Common Lisp implementation with CFFI and thread support is difficult. I regularly program on Mac OS X, Linux, and Windows; I need languages which work well on all three operating systems. Sadly, there are few Common Lisps that have working ports.

SBCL comes closest, but it crashes on Xen (so no Hunchentoot on my Gandi.net webserver).

CLISP has CFFI on Mac OS X, but only if you use "fink install ffcall && fink install clisp +dynffi to get it. MacPorts CLISP is no go. Even with Fink, CLISP lacks thread support. Homebrew CLISP isn’t any different, and I doubt DarwinPorts is either.

ECL lacks thread support on Mac OS X and Ubuntu.

ABCL takes time to setup: Install sun-java6-jdk. Download ABCL. Unzip ABCL. Move JAR to home. Add JAR to CLASSPATH. Create alias for JAR command. Install rlwrap. Generate completions. Modify alias to use rlwrap. Jump off bridge. Reload shell configuration. And after all that, ABCL lacks thread support according to Bordeaux Threads/Quicklisp.

CCL’s installation procedure is involved.

LispWorks and AllegroCL are proprietary. Obtaining valid license files is bothersome, and I don’t trust the projects to stay current.

OpenMCL and CMUCL are out of date and unavailable for modern Ubuntu versions.

XCL and WCL are maintained by very few people, and they must be manually compiled from source.

GCL is out of date, it fails to build with MacPorts, and Fink doesn’t even know it exists.

newlisp logoFark it, newLISP has a built-in web server, and it runs on Mac OS X, Windows, and Linux.

 

ccl logoUpdate: Lispbox is just what the doctor ordered. It has working CCL, Emacs, SLIME, Quicklisp, CFFI, and threads.

Writing Scripts with Common Lisp

lisp alienScripting languages such as Python and Ruby naturally lend themselves to the task of writing command line utilities. Lisp is much older than these languages, so it’s not surprising that some Lisp implementations are more difficult than others for scripting. Some lisps have a library too small to be useful. Some lisps cannot access files. But most of all, many lisps have trouble with shebangs and scripted main.

Shebangs

Add the following to ~/.cmucl-init.lisp (or your initialization file):

;;; Play nice with shebangs
(set-dispatch-macro-character #\# #\!
 (lambda (stream character n)
  (declare (ignore character n))
  (read-line stream nil nil t)
  nil))

This instructs CL to ignore all lines beginning with #!, even in the REPL.

Scripted Main

Java, Python, Perl, Ruby, Lua, Haskell, and newLISP all have scripted main.

One of the most useful tools in a scripting language is a scripted main. I invented this term out of necessity: it’s hard to Google something without a name. Scripted main refers to a special function, typically called main, which is executed when a script is run from the command line (e.g. python myscript.py or ./myscript.py). If the script is imported by another script, main() is not called. Scripted main is extremely useful for writing programs that do this:

$ ./welcome.py
Usage: ./welcome.py <name>
$ ./welcome.py Brandon
Welcome Brandon!

If another script greeter.py imports code from welcome.py, we don’t want greeter to call welcome‘s main function. The code in welcome that prints out Usage: ./welcome.py <name> probably calls sys.exit(0) soon after, which would kill greeter immediately after importing welcome.

How to do it

The next few examples are specific to CLISP. If you use SBCL, Clojure, or another implementation, you’ll need to modify the shebang lines accordingly.

Save as hello.cl:

#!/bin/bash
#|
exec clisp -q -q $0 $0 ${1+"$@"}
exit
|#
(defun hello-main ()
  (format t "Hello Main!~%")
  (quit))

(hello-main)

Run:

$ chmod +x hello.cl
$ ./hello.cl
Hello Main!

The chmod command marks hello.cl as a self-running executable so that ./hello.cl is allowed.

What if another script greeter.cl loads the code from hello? Let’s write a greeter that lets us choose which greeting to print.

Save as greeter.cl:

#!/bin/bash
#|
exec clisp -q -q $0 $0 ${1+"$@"}
exit
|#

(load "hello")

(defun greeter-main ()
  (format t "Ready to greet.~%")
  (quit))

(greeter-main)

Run:

$ chmod +x greeter.cl
$ ./greeter.cl
Hello Main!
Ready to greet.

The problem with this logic is that hello.cl‘s main function will be called as soon as the file is loaded. We don’t want this to happen, so we will use some special CMUCL code:

Resave as hello.cl:

#!/bin/bash
#|
exec clisp -q -q $0 $0 ${1+"$@"}
exit
|#

(defun hello-main (args)
  (format t "Hello from main!~%"))

;;; With help from Francois-Rene Rideau
;;; http://tinyurl.com/cli-args
(let ((args
       #+clisp ext:*args*
       #+sbcl sb-ext:*posix-argv*
       #+clozure (ccl::command-line-arguments)
       #+gcl si:*command-args*
       #+ecl (loop for i from 0 below (si:argc) collect (si:argv i))
       #+cmu extensions:*command-line-strings*
       #+allegro (sys:command-line-arguments)
       #+lispworks sys:*line-arguments-list*
     ))

  (if (member (pathname-name *load-truename*)
              args
              :test #'(lambda (x y) (search x y :test #'equalp)))
    (hello-main args)))

Resave as greeter.cl:

#!/bin/bash
#|
exec clisp -q -q $0 $0 ${1+"$@"}
exit
|#

(load "hello")

(defun greeter-main (args)
  (format t "Ready to greet.~%")
  (quit))

;;; With help from Francois-Rene Rideau
;;; http://tinyurl.com/cli-args
(let ((args
       #+clisp ext:*args*
       #+sbcl sb-ext:*posix-argv*
       #+clozure (ccl::command-line-arguments)
       #+gcl si:*command-args*
       #+ecl (loop for i from 0 below (si:argc) collect (si:argv i))
       #+cmu extensions:*command-line-strings*
       #+allegro (sys:command-line-arguments)
       #+lispworks sys:*line-arguments-list*
     ))

  (if (member (pathname-name *load-truename*)
              args
              :test #'(lambda (x y) (search x y :test #'equalp)))
    (greeter-main args)))

Now the mains function are only called when hello.cl orgreeter.cl are run directly, not when it is loaded.

Run:

$ ./hello.cl
Hello Main!
$ ./greeter.cl
Ready to greet.

This is the desired behavior. For more examples, check out problem.cl and sigil-clean.cl.

Syntactic barriers to learning Common Lisp

lisp logoFunctional programming is blessed to have several hardy languages. I have only tried two: Haskell and Common Lisp. From the few tutorials I’ve completed, it seems that Haskell is easy to learn, and Lisp hard to learn.

This difference is, I believe, due to Lisp’s various and sundry dialects, implementations, and macros. In Haskell, there are two major ways to specify local variables: let and where. Common Lisp has at least four: let, let*, flet, and labels. CL has a retarded number of loop constructs. I’m currently reading a sample chapter from Land of Lisp. Here is a code snippet:

(defun find-islands (nodes edge-list)
  (let ((islands nil))
    (labels ((find-island (nodes)
	       (let* ((connected (get-connected (car nodes) edge-list))
		      (unconnected (set-difference nodes connected)))
		 (push connected islands)
		 (when unconnected
		   (find-island unconnected)))))
      (find-island nodes))
    islands))

The defun syntax is intuitive; it’s like any other language’s function creator. And let makes sense: create some local variables and use them in sub-expressions. But labels baffles me. Would let have sufficed? Why or why not? After googling for a while (there is NO useable, complete Common Lisp reference document, and that includes HyperSpec and the Simplified Common Lisp Reference), I stumbled on a half-readable description of labels.

LABELS is special form for local function binding.

I could have told you that.

Bindings can be recursive and can refer to each other.

So labels is just like defun, defvar, and friends?

Each binding contains function name, arguments, and function body.

It seems that labels is just a special way to do defun locally. If Lisp is so powerful, why doesn’t Barkski do this:

(defun find-islands (nodes edge-list)
  (let ((islands nil))
    (defun find-island (nodes)
      (let* ((connected (get-connected (car nodes) edge-list))
	     (unconnected (set-difference nodes connected)))
	(push connected islands)
	(when unconnected
	  (find-island unconnected))))
    (find-island nodes)
    islands))

Nested functions don’t require special syntax in Haskell, Python, or Lua. Why should they in the premier functional language? I think the answer is that CL allows nested defuns, but lispers aren’t happy with that–they want a closure they can use in if, cond, and other non-code-block areas. A combination of let and lambda would do just that, but macro-addiction dictates that a new syntax be created. Now we have labels.

So that’s defun, let, and labels. Then there’s let*. Apparently let* is similiar to flet, which is similiar to labels , which is similar to let, except that I’ve forgotten where the fuck I was going with that. These macros are simply variations of let, some more powerful than others.

Land of Lisp does explain these macros, but if they weren’t used in the code, they wouldn’t have to be explained. Or, Barski could have used a separate example for each macro, but that would have taken more pages. There must be a balance between code simplicity and time to get the game running. I understand his dilemma. But if he errs to often on the side of code obscurity, then readers will simply close the book. I don’t know if I can write an informative and entertaining programming tutorial as well as Barski does, but I know what I like in one, and it’s not a never-ending stream of new syntax. I’m still going to buy the book, and I’m still going to love it. It’s just going to take longer for me to parse than I had expected.