I’ve made an image to describe Common Lisp method composition (or CLOS method composition if you want):
Tag: Common Lisp
-
SCons is a program designed to replace make and autotools. SCons being a new tool is built with all the knowledge of what problem really this kind of tool should be solving, while make and autotools were built while discovering the real problem. It is natural to expect SCons to have a better design that covers the big picture. (more…)
-
I recently stated what I believe is the biggest problem with Lisp, you can’t make programs with it. In my quest, my first solution is a very simplistic Makefile that does the job using cl-launch, a very interesting program that can turn a Common Lisp program into a Bash script. Other solutions are likely to use cl-launch as well.
So, we’ll play with this little program:
[sourcecode]
(defun main ()
(format t "Hello world!~%"))(main)
[/sourcecode]Very trivial indeed. And to “compile it”, we’d use this trivial Makefile:
[sourcecode]
%: %.lisp
cl-launch –output $@ –file $&<hello-world: hello-world.lisp
[/sourcecode]All we have to do now is run make:
[sourcecode]
$ make
cl-launch –output hello-world –file hello-world.lisp
[/sourcecode]And we now have a runable hello-world:
[sourcecode]
$ ./hello-world
Hello world!
[/sourcecode]It run! it worked! it’s portable! Isn’t it great?
Obviously all the logic is hidden inside cl-launch (thank you Fare Rideau). The problems with this simple solution is that using only make makes programs harder to port and package for different distributions and operating systems. That’s why the autotools where invented. Remember those days when to compile something we had to open a Makefile and set up variables? well, this simplistic solution is going back to those days. We can do better, I hope I can do better.
Now, for the curious, this is how the hello-world script looks like (I’d say its quite remarkable):
[sourcecode lang=”bash”]#!/bin/sh
#| CL-LAUNCH 2.03 CONFIGURATION
SOFTWARE_FILE=.
SOFTWARE_SYSTEM=
SOFTWARE_INIT_FORMS=
SYSTEMS_PATHS=
INCLUDE_PATH=/usr/share/common-lisp/source/cl-launch
LISPS="cmucl sbcl clisp ecl openmcl gclcvs allegro lisp gcl"
WRAPPER_CODE=
DUMP=
RESTART=
IMAGE_BASE=
IMAGE_DIR=
IMAGE=# END OF CL-LAUNCH CONFIGURATION
# This file was generated by CL-Launch 2.03
# This file was automatically generated and contains parts of CL-Launch
#
PROG=""
. /usr/share/common-lisp/source/cl-launch/wrapper.shlaunch_self "$@"
ABORT
# |#
(load "/usr/share/common-lisp/source/cl-launch/header.lisp" :verbose nil :print nil)
;;;; CL-LAUNCH LISP INITIALIZATION CODE
#-cl-launched
(cl-launch::run :load :self);;;; END OF CL-LAUNCH LISP INITIALIZATION CODE
;;; 65bcc57c2179aad145614ec328ce5ba8 SOFTWARE WRAPPED BY CL-LAUNCH BEGINS HERE:
(defun main ()
(format t "Hello world!~%"))(main)
[/sourcecode] -
I’m not really going to talk about the problem with Lisp, but only a problem. And I’m not really going to talk about Lisp, but Common Lisp. So this post should be called “A problem with Common Lisp”, but the current title is more catchy, isn’t it?
You are still with me? nice. Because I believe I have something important to say. A problem with Common Lisp is that you can’t make programs with it. That may have been another nice catchy title: “You can’t make programs with Lisp”. (more…)
-
I’ve discovered something recently. Most programmers have a favourite programming language. No, that’s not it, there’s more to my discovery. Whenever those programmers have an idea they open a text editor and start coding and/or they start playing with a REPL, if they are lucky to like a programming language that provides one.
You watch them code and they do it fast, with little errors. They don’t program fast because it’s a good language, they program fast because they know it, and they know it because they use it often, and they do that because they like it. That was the first part of my discovery. (more…)
