Planet Lisp

Joe Marshalln-ary functions and argument lists

· 8 hours ago
Suppose we have a binary operation Op2 = (lambda (left right) ...). If it is closed over some type, you can make expression trees.
(Op2 (Op2 <arg1> <arg2>)
          (Op2 <arg3> <arg4>)
If Op2 is associative as well, these are equal:
(Op2 (Op2 <arg1> <arg2>)
     (Op2 <arg3>
         (Op2 <arg4> <arg5>)))

(Op2 <arg1> 
     (Op2 (Op2 <arg2> <arg3>)
          (Op2 <arg4> <arg5>)))

This makes the tree structure irrelevant so long as the fringe of the tree stays in order, so we can flatten the tree by making an N-ary version of the binary operation:
(define (binary->nary Op2)
  (lambda (a1 a2 . an)
    (fold-left Op2 (Op2 a1 a2) an)))

((binary->n-ary Op2) <arg1> <arg2> <arg3> <arg4> <arg5> <arg6> etc.)
The value of this expression naturally depends upon the values of the arguments. Changing the argument list is highly likely to change the value of the entire expression. However, we can make certain changes to the argument list without changing the value of the entire expression. If we know what those changes are, we can manipulate the argument list before invoking the operator, and still get the same answer. Naturally, most of the changes we can make to the argument list depend on the specifics of Op2, but it turns out that some interesting changes are possible without knowing any specifics, only knowing a few high-level properties of Op2.

Obviously, the first thing we can do is reduce the argument list through evaluation. Simply replace the first two arguments with the value of (Op2 <arg1> <arg2>)
((binary->n-ary Op2) <arg1> <arg2> <arg3> <arg4> <arg5> <arg6> etc.) =

((binary->n-ary Op2) (Op2 <arg1> <arg2>) <arg3> <arg4> <arg5> <arg6> etc.) =

((binary->n-ary Op2) <result> <arg3> <arg4> <arg5> <arg6> etc.)
Since Op2 is associative, we can replace any 2 adjacent arguments with their combination.

Now suppose there is an identity element among the arguments we can give to Op2.
(Op2 <arg> id) = <arg>  and
(Op2 id <arg>) = <arg>
We can do this:
(define (binary->nary Op2)
  (lambda an
    (fold-left Op2 id an)))

(define Op (binary->nary Op2))
Which is cleaner than the original. We also get a new way to manipulate the argument list to Op. We can add the identity element anywhere we wish, or we can delete the identity element wherever we find one.
(Op <arg1> <arg2> <arg3> Id <arg4> <arg5> <arg6> etc.) =

(Op <arg1> <arg2> <arg3> <arg4> <arg5> <arg6> etc.) =

(Op <arg1> Id <arg2> <arg3> <arg4> <arg5> Id <arg6> etc.)

One more restriction. We want Op2 to be invertible. Suppose (Op2 <arg1> <arg2>) = <result>. Op2 is invertible if, given any two of <arg1>, <arg2>, and <result>, the third can be uniquely determined. If you have one <arg> and a <result>, you can run things backwards and get the other <arg>.

Requiring Op2 to be invertible has many consequences, some of them quite non-obvious. An obvious consequence, though, is that we can define inverse elements. If (Op2 <argA> <argB>) = Id, then we say that <argB> is the inverse of <argA> (and vice versa). We find the inverse of an argument by fixing the output as the identity element and running Op2 backwards to find the other argument.

This gives us the final way to manipulate the argument list. If an element appears next to its inverse, both can be removed:
(Op <arg1> <arg2> <arg3> (inverse <arg3>) <arg5> <arg6> etc.) =
(Op <arg1> <arg2> (Op2 <arg3> (inverse <arg3>)) <arg5> <arg6> etc.) =
(Op <arg1> <arg2> Id <arg5> <arg6> etc.) =
(Op <arg1> <arg2> <arg5> <arg6> etc.)

So here are all the restrictions on Op2:
  • Closed over an set of arguments
  • Associative
  • Has an identity argument
  • Invertible
If Op2 has these properties (and a lot of binary operations do), then we can define an n-ary Op and play with its argument list. If you do this, you might notice that it looks kind of familiar:
(op f g (inverse g) j id h) = (op f j id h) = (op f j h)

The argument list sort of looks like a function pipeline. The allowed manipulations of the argument list are compatible with a function pipeline, too. In fact, it could be a function pipeline if Op is the compose operator, and f, g, and h are appropriate invertible unary functions. But whatever it is, the point is that it looks enough like a function pipeline that we can pretend that it is.

Michael MalisDefaddress

· 22 hours ago

This post is the first part of a two part series exploring the emulator cl-6502. This post will cover how addressing modes are implemented in cl-6502. The second part will go over the implementation of the opcodes.

cl-6502 is an emulator for the MOS 6502 processor, used in devices such as the Apple II and the NES. As an emulator, cl-6502 has three distinct roles. It needs to be able to convert assembly code into machine code (assembly), it needs to be able to convert machine code back into assembly (disassembly), and it needs to be able to actually interpret the machine code (execution). By using macros in clever ways, cl-6502 is able to create multiple DSLs for defining different components of the emulator. One of those macros is defaddress, which makes it easy to add addressing modes to the emulator. First some background.

Assembly language has what are known as “addressing modes”. Depending on which addressing mode is being used, the argument to the instruction will be calculated in a different manner. The programmer is able to specify different addressing modes by using slightly different syntaxes. As an example here is the same jump instruction just with two different addressing modes:

JMP $0
JMP ($0)

From here on out, I’m going to use the term “operand” to refer to the value given to the instruction before the addressing mode has been taken into account and the term “argument” to refer to the value after the addressing mode has been considered. As you should be able to tell, both instructions above are passed the same operand of zero, but because they are using different addressing modes, they will calculate their arguments in two different ways.

Since the first instruction doesn’t use any extra syntax (except the dollar sign which just means base 16), it uses “absolute” addressing. With absolute addressing the argument is the same as the operand.1 The first instruction can be read as, continue execution at the instruction at address zero.

Since the second instruction has parens around the operand, it uses what is known as “indirect” addressing. For indirect addressing, the operand is actually the memory location of the argument.2 The second instruction can be read as, get the address that is stored at address zero, and continue execution at the instruction at that location in memory. Assuming the value 123 was stored at address zero, the operand would be zero, the argument would be 123, and the instruction would cause execution to be resumed at the instruction at location 123.

In total there are 13 different addressing modes for the 6502. In order to make it easy to define all of these different addressing modes, cl-6502 creates a macro defaddress. Defaddress is a DSL for the sole purpose of defining addressing modes. Each one of the main arguments to defaddress handles one of the jobs (assembly/disassembly/execution) that an emulator has to perform with respect to the addressing mode. As to what the defaddress DSL looks like, here is the code that defines the absolute addressing mode.

(defaddress absolute (:reader "^_$" :writer "$~{~2,'0x~}")
  (get-word (cpu-pc cpu)))

The code above has three distinct parts. The first piece is the reader, which is used to parse the assembly code:


The reader argument is a regular expression that recognizes the syntax of the addressing mode being defined, in this case aboslute addressing. The regex is a normal perl compatible regex except it may use an underscore to match (and capture) an operand. The regex above matches a lone operand, which is exactly the syntax for absolute addressing. After the reader is the writer:


The writer is a format string that is able to reproduce the original assembly (with the proper syntax for the addressing mode) from the machine code. The writer for absolute addressing says to print the operand as a zero padded, two digit, hexadecimal number. Basically, it just prints the lone operand in assembly language without any additional syntax. Since there is no extra syntax, that means the generated code is using absolute addressing.

The last part is the body. The body is a block of code that calculates the argument from the operands.3 For absolute addressing the body is:

(get-word (cpu-pc cpu)) 

When this code is ran, the variable cpu will be bound to an object representing the current state of the cpu. The pc of the cpu normally points to the current instruction being executed, but cl-6502 uses a slight trick. By incrementing the pc, it will now point to the first operand of the instruction! All the body does is take the value of the pc (which is the address of the argument/operand), and looks up the value at that address4 to get the actual argument.

As a second example of defaddress, here is the code for indirect addressing:

(defaddress indirect (:reader "^\\(_\\)$" 
                      :writer "($~{~2,'0x~})")
  (get-word (get-word (cpu-pc cpu)) t))

There are only a few differences between the code for indirect and absolute addressing. In the reader and writer, there are now an extra pair of parens around the operand. This is because the syntax for indirect addressing is an operand surrounded by parens. Another difference is with the body. Since there is an extra layer of indirection with indirect addressing, there is an additional call to get-word. For indirect addressing, the body says to calculate the argument, get the value of the pc (the address of the operand or the address of the address of the argument), get the value at that address (the operand or the address of the argument), and then get the value at that address (the actual argument).

Since I have already shown you some examples of how to use defaddress, I am now going to explain how defaddress works. Here is the complete definition of defaddress:

(defmacro defaddress (name (&key reader writer cpu-reg)
                      &body body)
    (defmethod reader ((mode (eql ',name)))
         "_" reader "([^,()#&]+)"))
     (defmethod writer ((mode (eql ',name))) ,writer)
     (push ',name *address-modes*)
     (defun ,name (cpu) ,@body)
     (defun (setf ,name) (value cpu)
       ,(if cpu-reg
            `(setf ,@body value)
            `(setf (get-byte ,@body) value)))))

I’m going to break down the code for defaddress one part at a time. After explaining a piece does, I will show you what the expansion of that piece looks like when defining absolute addressing. The first part of defaddress handles the reader:

 (defmethod reader ((mode (eql ',name)))
   ,(cl-ppcre:regex-replace-all "_" reader "([^,()#&]+)")) 

This part generates code which will define a method on the generic (virtual) function reader. Reader takes in the name of the mode as an argument and is supposed to return a regex (a true perl compatible regex, i.e. no underscores) that will recognize the mode and extract the operands:

(reader 'absolute)
=> "^([^,()#&]+)$"

To produce the method, defaddress just takes the reader argument, substitutes the underscore with a regex that can be used to recognize operands, and uses that as the value reader should return for the mode being defined. Here is what the piece of code expands into for absolute addressing:

(defmethod reader ((mode (eql 'absolute))) "^([^,()#&]+)$")

The next part does pretty much the exact same thing, only for the writer:

(defmethod writer ((mode (eql ',name))) ,writer)

It generates the code for a method for the generic function writer. Since the format string is used unmodified, defaddress just inserts the string into the body of the function. There result winds up being:

(defmethod writer ((mode (eql 'absolute))) "$~{~2,'0x~}")

Next up is the piece:

 (push ',name *address-modes*) 

This piece of code adds the mode being defined to a list of all of the addressing modes. The list is used to find all of the addressing modes that match the syntax of a given instruction. The snippet simply expands into:

(push 'absolute *address-modes*)

Now for the most important part of defaddress – the code that handles the body:

 (defun ,name (cpu) ,@body) 

It just puts the body inside of a function named by the addressing mode. The function is supposed to take the in the current state of the cpu as an object and return the argument used for the current instruction. Note that the variable cpu is available to the body. This is how the body of defaddress is able to access the cpu object. The expansion winds up looking like:

(defun absolute (cpu) (get-word (cpu-pc cpu)))

There is just one more part, a setf function for the addressing mode:

(defun (setf ,name) (value cpu)
  ,(if cpu-reg
       `(setf ,@body value)
       `(setf (get-byte ,@body) value)))

This code generates a setf function, basically a way to modify the argument of the instruction. Many instructions not only use the argument, but they store a new value to the memory location of the argument. The setf function defined by defaddress is just a way to do that. I’m not going to go in depth about it, but this is the only piece of code that uses the cpu-reg argument. The cpu-reg argument is just used to smooth out some differences between different addressing modes. The code generated by the above code winds up looking like:

(defun (setf absolute) (value cpu)
   (setf (get-byte (get-word (cpu-pc cpu))) value))

As I just said, the setf function defined can be used to set the value of the argument. To do it for absolute addressing, get the operand and set the value at that memory location.56

And that is pretty much everything there is to know about defaddress. In the next post I am going to talk a bout defasm, a macro that makes it easy to define different instructions for the emulator. It piggybacks off of the information provided by defaddress in order to handle all of the instructions in all of the different possible addressing modes.

The post Defaddress appeared first on Macrology.

Zach BeaneJean-Philippe Paradis really, really, really wants you to know about his stuff

· 2 days ago

In the past few years, I haven't had as much time to write about Common Lisp stuff as much as I did before.

For a while, I used a bookmarking tool to collect links to interesting stuff and periodically post them, a la Christian Neukirchen’s Trivium. But I fell behind at that, and stopped. These days, I often find neat Lisp stuff and think “I should write about that on my blog!” However, the link often ends up as a tweet, a reddit link, or disappears into the bottom half of my todo list.

I talked about the general slowdown in Planet Lisp blogging at ELS in London. Compared to ten years ago, the usual people just aren’t writing as much, for various reasons. It wasn’t only doom and gloom, though. ELS was also an energizing experience, with a lot of excitement, positivity, and enthusiasm for Common Lisp. It gave me renewed energy for writing about CL stuff and linking to new CL things.

Then yesterday, out of left field, someone asked me what I thought about the recent @HexstreamSoft twitter rants.

Take a minute to browse through @HexstreamSoft. I’ll wait. (NSFW language and images.)

There are two resources he created that seem to have set off the latest rants. First, there is a format reference. Second, there is a Common Lisp symbol reference. The former looks fairly complete, and presents information in an interesting way. The latter looks mostly incomplete.

There is no conspiracy on my part to suppress these links. I’m not sure I saw them before yesterday, though it’s possible I saw them and forgot about them. But while I’d like to post more links and share more cool Lisp stuff, it’s not my personal responsibility to plug everything that comes along. The world’s lack of interest in a resource cannot be laid solely at my feet.

Unfortunately, conspiracy theories and rants sap my energy; fortunately, this seems like a fairly uncommon thing. (Madhu is the only other person I know of who sees a nefarious conspiracy in my work.)

If you’d like to see your work featured on Planet Lisp, one of the best ways is to start your own blog full of useful Common Lisp articles, add an RSS or Atom feed, and tell me about it. (If you have lots of energy and want to start a blog linking to every cool new CL thing, that would be great too!)

Another way to get featured on Planet Lisp, one I do not especially prefer, is to take to twitter and rant about the Common Lisp mafia. It worked this time, but I’m not inclined to respond to that type of thing again.

Eugene ZaikonnovCL-JPEG has been updated

· 2 days ago

A long due update to Common Lisp JPEG Library has now been merged into sharplispers/cl-jpeg.

The summary of changes:

  • The various global state tables and counters were moved into special variables of decoder/encoder functions. This should address the concerns of thread safety.
  • The monolithic source file was broken up into several according with modern way of structuring the projects.
  • Metadata for :author and :description was added to the project's .asd.
  • The contributors are now listed. Do let me know if I forgot to add someone.

Revisiting own 16 year old code was an interesting experience. Thanks to everyone who kept the project alive over the years.

Common Lisp TipsWhen a synonym-stream is useful

· 3 days ago

Imagine your project has a special variable whose value is a stream to which some output is directed, e.g. my-project:*log-output*. You can change where the output goes by setting the value of the special variable, but by default, output should go to *standard-output*.

The naive way to do this is a direct reference:

(defvar *log-output* *standard-output*)

However, this can run into trouble if *standard-output* is bound to something unexpected when that form is evaluated. For example, if file loading output is temporarily suppressed by binding *standard-output* to (make-broadcast-stream), output to *log-output* is then also discarded.

One way to work around it is with make-synonym-stream:

(defvar *log-output* (make-synonym-stream '*standard-output*))

With that setup, any output sent to *log-output* is sent to the stream that is the dynamic value of the symbol '*standard-output*. And since the dynamic value is looked up for each output, the output to *log-output* will go to *standard-output* even if *standard-output* is assigned some other stream value later on.

Joe MarshallPlaying with linear fractional transforms

· 4 days ago
I wanted to play with continued fractions and linear fractional transforms, so I wrote some code to make it easier. A linear fractional transform (also called a homographic function or Mobius transform) is a function like this:
In MIT/GNU Scheme:
;; x => (3x + 1)/(x + 4)

1 ]=> (define foo (make-linear-fractional-transform 3 1 1 4))

;Value: foo

1 ]=> (foo 2)

;Value: 7/6
I used an entity object so, in addition to invoking it on a number, there are two more ways to manipulate a linear fractional transform:
;; A predicate
1 ]=> (linear-fractional-transform? foo)

;Value: #t

;; And a CPS accessor
1 ]=> (lft/spread-coefficients foo (lambda (A B C D) (list A B C D)))

;Value 307: (3 1 1 4)
I also added a print method:
1 ]=> foo

;Value 308: #[linear-fractional-transform 308 (3x + 1)/(x + 4)]

As I mentioned in a prior post, you can partly apply a linear fractional transform:
1 ]=> foo

;Value 308: #[linear-fractional-transform 308 (3x + 1)/(x + 4)]

1 ]=> (lft/partly-apply foo 2)

;Value 315: #[linear-fractional-transform 315 (7x + 3)/(6x + 1)]
Since I want to reason about applying a linear fractional transform to an argument, I wrote an abstraction for that:
;; Apply LFT foo to continued fraction phi.
1 ]=> (make-lft-application foo phi)

;Value 311: #[lft-application 311 (3x + 1)/(x + 4) {1 ...}]
So now we can write a procedure that takes an application, peels off the first term in the continued fraction, feeds it to the linear fractional transform, and creates a new application:
(define (application/step lft-application)
  (let ((lft (application-function lft-application))
 (cf  (application-continued-fraction lft-application)))
     (lft/partly-apply lft (head cf))
     (tail cf))))

1 ]=> (define appl (make-lft-application lft/identity sqrt-two))

;Value: appl

1 ]=> appl

;Value 317: #[lft-application 317 x {1 2 2 2 ...}]

1 ]=> (application/step appl)

;Value 318: #[lft-application 318 (x + 1)/x {2 2 2 ...}]

1 ]=> (application/step (application/step appl))

;Value 319: #[lft-application 319 (3x + 1)/(2x + 1) {2 2 ...}]

1 ]=> (application/step (application/step (application/step appl)))

;Value 320: #[lft-application 320 (7x + 3)/(5x + 2) {2 ...}]
All these lft-application objects should be (numerically) equal.

In an earlier post I showed how a linear fractional transform can be partly evaluated by determining the integer-part of the transform. The integer-part of an application is the integer-part of the application-function. You can get the fractional part by subtracting the integer-part.

A digression

If you apply a linear fractional transform to zero, it's obvious the answer is B/D. On the other hand, if you apply a transform to a sufficiently large x, you'll get as close as you want to A/C.

If the denominator of a linear fractional transform is zero for some value of x, there should be a vertical asymptote at that point. That's the pole of the transform. The pole is at (- D)/C. The pole will be at zero if D is zero. It will be at a negative number if D and C are the same sign and at a positive number if D and C differ in sign.

If you take a linear fractional transform with a pole at a negative number, and you sweep the input from 0 up on to infinity, the output will vary smoothly and monotonically from B/D approaching A/C and staying between both values at all times.
1 ]=> lft1

;Value 675: #[linear-fractional-transform 675 (3x + 1)/(4x + 2)]

1 ]=> (lft1 0)

;Value: 1/2

1 ]=> (lft1 1000000)

;Value: 3000001/4000002

1 ]=> (exact->inexact 3000001/4000002)

;Value: .7499998750000625

(On the other hand, if the pole is at a positive number, as you sweep the input from 0 up to infinity, the output starts at B/D, but flees away from A/C until the input gets to the pole. Then the output approaches A/C, but from the opposite direction. In any case, if the pole is positive, then the output will vary from B/D and eventually approach A/C, but never being between them.)

We can represent intervals as linear fractional transforms. The endpoints of the interval are A/C and B/D.

To get the width of the interval, just subtract the endpoints: A/C - B/D = (A*D - B*C)/(C * D)

Imagine you are performing some calculation with continued fractions. Since there may be an infinite number of terms, the calculation will proceed incrementally, using up terms as needed and generating other terms. So you can think of a more complex calculation as a tree, where a node in the tree is a linear fractional transform and the continued fraction terms flow between the nodes.

When we do an application/step, we move a term from the continued fraction into the linear fractional transform. Now consider a term as an element of information. We've moved this information out of the continued fraction and into the linear fractional transform. The information is apparently "stored" in the linear fractional transform until it is extracted as an output term for the next stage in the computation. But if you think about it, the "format" of the information is different depending upon whether it is flowing between nodes, where it is a series of continued fraction terms, or if it is stored in a linear fractional transform, where it is encoded somehow in the values of the coefficients. The act of partly-evaluating a linear fractional transform is in effect "encoding" some information as a continued fraction term. Partly applying a linear fractional transform is in effect "decoding" the continued fraction term (presumably generated by an earlier computation). Why not change to a more efficient communication channel?

When a node sends information to another node, instead of converting the information to several continued fraction terms to be assembled at the other end, we'll send the information as a single linear fractional transform. It contains the desired information already in the right "format". (See Peter Potts's work.)

A digression

What happens if we compose two linear fractional transforms?
(compose (lambda (x)
           (/ (+ (* A x) B)
              (+ (* C x) D)))
         (lambda (y)
           (/ (+ (* p y) q)
              (+ (* r y) s))))
We get
(lambda (x)
   (/ (+ (* A (/ (+ (* p x) q)
                 (+ (* r x) s))) B)
      (+ (* C (/ (+ (* p x) q)
                 (+ (* r x) s))) D)))
Which, after some algebra, turns into this:
(lambda (x)
   (/ (+ (* (+ (* A p) (* B r)) x) (+ (* A q) (* B s)))
      (+ (* (+ (* C p) (* D r)) x) (+ (* C q) (* D s)))))
Which is equivalent to this:
(lambda (x)
  (let ((E (+ (* A p) (* B r)))
        (F (+ (* A q) (* B s)))
 (G (+ (* C p) (* D r)))
 (H (+ (* C q) (* D s))))

   (/ (+ (* E x) F)
      (+ (* G x) H))))
Which you can see is another linear fractional transform.

If we have a linear fractional transform
(lambda (x)
  (/ (+ (* A x) B)
     (+ (* C x) D)))
It's inverse (if it has one) is:
(lambda (x)
  (/ (+ (* D x) (- B))
     (+ (* (- C) x) A))))
Which is yet another linear fractional transform. These things are everywhere.

Let's see, if we have a binary operation binop that is
  1. Closed over some set, i.e. given any two elements of the set, the operation applied to the elements produces another element of the set. In other words, binop takes two arguments, returns one value, and the type of both arguments and return value are the same.
  2. Associative, i.e. (binop a (binop b c)) = (binop (binop a b) c)
  3. Has an identity argument. A "left identity" is an argument such that (binop left-identity x) = x. A "right identity" is an argument such that (binop x right-identity) = x. An "identity" argument works as a left or right identity.
  4. Is invertible, i.e. for any objects a and b, there is a unique object x such that (binop a x) = b and a unique object y such that (binop y b) = a

then we have a group.

The compose function is a binary operation. When you compose a linear fractional transform with another, you get a third linear fractional transform.
1 ]=> (define lft1 (make-linear-fractional-transform 3 1 4 2))

;Value: lft1

1 ]=> (define lft2 (make-linear-fractional-transform 5 1 1 0))

;Value: lft2

1 ]=> (lft/compose lft1 lft2)

;Value 662: #[linear-fractional-transform 662 (16x + 3)/(22x + 4)]
Linear fractional transforms are associative.
1 ]=> (define lft3 (make-linear-fractional-transform 7 2 1 3))

;Value: lft3

1 ]=> (lft/compose lft1 (lft/compose lft2 lft3))

;Value 663: #[linear-fractional-transform 663 (115x + 41)/(158x + 56)]

1 ]=> (lft/compose (lft/compose lft1 lft2) lft3)

;Value 664: #[linear-fractional-transform 664 (115x + 41)/(158x + 56)]

The linear fractional transform (make-linear-fractional-transform 1 0 0 1) is both a left and right identity when composed with another linear fractional transform.
1 ]=> (define lft/identity (make-linear-fractional-transform 1 0 0 1))

;Value: lft/identity

1 ]=> (lft/compose lft/identity lft1)

;Value 665: #[linear-fractional-transform 665 (3x + 1)/(4x + 2)]

1 ]=> (lft/compose lft1 lft/identity)

;Value 666: #[linear-fractional-transform 666 (3x + 1)/(4x + 2)]
Given lft1 and lft2, there is a unique linear fractional transform x such that (compose lft1 x) = lft2, and a unique linear fractional transform y such that (compose y lft1) = lft2. x should be (compose (inverse lft1) lft2), and y should be (compose lft2 (inverse lft1))
1 ]=> lft1

;Value 675: #[linear-fractional-transform 675 (3x + 1)/(4x + 2)]

1 ]=> lft2

;Value 687: #[linear-fractional-transform 687 (5x + 1)/x]

1 ]=> (define x (lft/compose (lft/inverse lft1) lft2)))

;Value: x

1 ]=> (lft/compose lft1 x)

;Value 690: #[linear-fractional-transform 690 (5x + 1)/x]

1 ]=> (define y (lft/compose lft2 (lft/inverse lft1)))

;Value: y

1 ]=> (lft/compose y lft1)

;Value 691: #[linear-fractional-transform 691 (5x + 1)/x]
It sure looks like linear fractional transforms form a group under function composition.
I guess it's time to learn a little group theory.

Quicklisp newsJuly 2015 download stats

· 4 days ago
Here are the top 100 downloads for July, 2015:

13137 alexandria
8723 trivial-features
8303 babel
7185 cffi
7095 bordeaux-threads
6398 trivial-gray-streams
6269 flexi-streams
5246 trivial-garbage
5126 usocket
5072 closer-mop
4989 cl-fad
4772 cl-ppcre
4725 split-sequence
4659 anaphora
4599 cl+ssl
4317 cl-base64
4159 chunga
4097 puri
4022 drakma
3916 iterate
3842 nibbles
3773 chipz
3256 named-readtables
3183 ironclad
2816 md5
2816 local-time
2783 let-plus
2741 slime
2702 uiop
2595 trivial-backtrace
2507 cl-colors
2375 hunchentoot
2313 cl-ansi-text
2263 prove
1924 cl-unicode
1900 rfc2388
1900 metabang-bind
1863 trivial-types
1860 cl-utilities
1821 cl-annot
1806 optima
1777 fiveam
1717 cl-interpol
1700 cl-syntax
1629 static-vectors
1583 trivial-utf-8
1580 quri
1466 parse-number
1450 fast-io
1418 salza2
1322 clack
1313 quicklisp-slime-helper
1296 cl-json
1226 proc-parse
1137 xsubseq
1092 jonathan
1068 fast-http
1036 ieee-floats
1025 osicat
1019 closure-common
1018 lack
959 cxml
957 asdf-system-connections
937 zpb-ttf
935 http-body
914 uuid
897 postmodern
893 hu.dwim.asdf
876 trivial-indent
860 zpng
835 plump
833 cl-dbi
827 esrap
818 fare-utils
813 jsown
812 array-utils
806 cl-who
776 cl-yacc
754 metatilities-base
746 symbol-munger
720 swap-bytes
719 yason
718 cl-containers
711 trivial-mimes
695 fare-quasiquote
687 lisp-unit
686 clss
662 lquery
648 cl-vectors
636 iolib
626 myway
626 map-set
625 parenscript
608 lparallel
607 arnesi
605 log4cl
592 hu.dwim.stefil
588 cl-marshal
585 vom
578 external-program

Michael MalisDebugging Lisp Part 5: Miscellaneous

· 8 days ago

This post is for all of the miscellaneous features that aren’t large enough to get their own individual posts. If you haven’t read all of them, here are the links to the previous posts on recompilation, inspection, class redefinition, and restarts.

One somewhat obscure tool for debugging is SBCL’s trace. SBCL’s trace goes way beyond what most other implementations provide. In SBCL, trace takes several additional keyword arguments.1 For example, trace accepts a keyword argument, :break. The expression passed in as the value of :break will be evaluated every time the traced function is called. When that expression evaluates to true, the debugger will be invoked. For example if you have a Fibonacci function:

(defun fib (n)
  (if (<= 0 n 1)
      (+ (fib (- n 1))
         (fib (- n 2)))))

you can use trace to break specifically when fib is called with an argument of zero: (4)


A bit of mangling has to be done (using sb-debug:arg) since the expression refers to variables within the fib function. Trace also accepts several variants of :break, such as :break-after, which evaluate the expression after the function has been called instead of before. There are also arguments :print and :print-after, which are like their break counterparts, only they print the value of the expression before/after the function is called. You could use :print-after to say, print the time (Unix time) whenever fib returns: (6)


For a complete list of all of the arguments that trace can accept, check out this page of the SBCL manual.

Another relatively unknown group of features are the cross referencing commands. The cross referencing commands are commands which lookup all of the places where something is referenced. All of the bindings for the cross referencing commands begin with C-c C-w.2 The cross referencing command I find myself using the most, “slime-who-calls”, which is bound to C-c C-w C-c, shows you all of the places where a function is called from. Here is what it would look like if you were to lookup all of the places where the scan function is used in cl-ppcre and then scroll through them:3 (7)


Slime-who-calls makes it easy to figure out how a function is supposed be used. You can pull up all of the usages of a function and just look at them. There are also several analogs of slime-who-calls. There is slime-who-macroexpands (C-c C-w RET), which pulls up all of the places where a macro is used and there is also slime-who-references (C-C C-w C-r) which is the same thing only for variables.

Another important feature is how to pull up the source code of a function on the stack while inside of the debugger. One way to do it is to press the ‘v’ key with the cursor on the frame you want to view the source of. An alternative option is to use M-p (the alt key and the ‘p’ key at the same time) and M-n to move up and down the stack frame. When using these commands instead of the normal C-p and C-n for movement, Slime will automatically pull up the source code as you are moving through the stack. Here is what it would look like if you were to pass a malformed regular expression to cl-ppcre (so that an error will be signaled and you will enter the debugger), and then scroll through the stack trace using M-n: (9)


And now for the most common of all IDE commands, jumping to source. I was recently talking with someone and he mentioned that the only feature he uses an IDE for is to easily find definitions in source code. In Emacs with Slime, it is possible to jump to the source of pretty much anything by hitting “C-.” (that is the control key followed by a period). This command works on functions, variables, classes, and more! When you jump to the source of a generic (virtual) function, you are given a list of all of the different methods that implement that function. For example if you weret to jump to the source of create-matcher-aux (the function that does most of the work in cl-ppcre), here is what you would see: (8)


To jump back to wherever you were previously, use “C-,”.

And that is everything you should need to know about debugging Common Lisp.

The post Debugging Lisp Part 5: Miscellaneous appeared first on Macrology.

LispjobsClojure Developer, Disco Melee, Remote

· 16 days ago

Disco Melee | Full Time or Part Time or Freelance | 100% Remote
In search of Clojure developers.

–About Us–
Disco Melee was founded by gamers, for gamers, to deal with with the lack of social features in other gaming-centric sites, and to reinvent the concept of social streaming. Basically we are “making gaming social again”. We’re in closed beta now, but will be opening up very soon!

–What We’re After–
The frontend is built in Clojurescript and Om, the backend in Clojure on a PostgreSQL database.
While we do require some degree of prior experience with these technologies, we also greatly value an ability to learn, take ownership, be proactive, and communicate well with others.

Essential skills:
* Good written and spoken English
* Functional programming techniques

* Modern HTML and CSS (LESS)/Bootstrap
* Clojurescript (and Javascript)
* React (Om)
* Implementing a Photoshop design in HTML/CSS

* Clojure
* SQL (we use PostgreSQL)

Desirable skills:
* Data security and privacy
* JVM familiarity (ecosystem)
* XMPP protocol knowledge
* Video streaming/web video familiarity
* Distributed systems
* Payment processors
* Mobile (iOS/Android) knowledge
* Familiarity with Amazon Web Services

To submit your resume for consideration, please email

Zach BeaneSyntax for reading a form in a package

· 18 days ago

Allegro, GCL, SBCL, and possibly other implementations support a syntax that looks like this:

foo::(bar 'baz 42)

A form like that is read as though you had written (foo::bar 'foo::baz 42). I use this syntax sometimes for Quicklisp operations that rely on ql-dist symbols, like installing all available Quicklisp projects:

ql-dist::(map nil 'ensure-installed (provided-systems (dist "quicklisp")))

It’s easier than changing *package* or qualifying all symbols.

I don’t know the origin of this reader extension; a crude grep of my comp.lang.lisp archive suggests it originated on Symbolics. Whatever the origin, it’s pretty handy, and I’m glad it’s part of my favorite implementation.

Zach BeaneUpdated package locking behavior with SBCL 1.2.14

· 21 days ago

SBCL 1.2.14 came out last week. I test all Quicklisp libraries on SBCL, so when there is a change in how SBCL works, it can have an effect on which libraries build and which don't.

SBCL has had package locks for a long, long time. Among other things, they enforce the restrictions of section of the spec. The COMMON-LISP package is locked by default, so SBCL will signal an error if e.g. you try to define a function named CL:CAR.

1.2.14 updates package locking to include’s prohibition on defining CL symbols as constants. This triggered build failures in a number of Quicklisp projects; they had constants defined for CL:DO, CL:ERROR, CL:QUOTE, and other symbols. The error looks like this:

Lock on package COMMON-LISP violated when
defining DO as a constant while in package COMMON-LISP-USER.
   [Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]
See also:
  SBCL Manual, Package Locks [:node]
  Common Lisp Hyperspec, [:section]

These projects were not intentionally using CL symbols; the symbol names were natural for the task at hand (e.g. supporting a non-Lisp protocol or API that used those names).

Most of the broken projects have been fixed. But a few (cl-gearman, read-csv) remain broken under SBCL 1.2.14.

Just something to be aware of if you upgrade to SBCL 1.2.14.

Michael MalisDebugging Lisp Part 4: Restarts

· 22 days ago

This is part four of Debugging Lisp. Here are the previous parts on recompilation, inspecting, and class redefinition.

Many languages provide error handling as two distinct parts, throw and catch. Throw is the part that detects something has gone wrong and in some way signals that an error has occurred. In the process, throw creates an exception object which contains information about the problem. The other part, catch, takes the exception object signaled by throw and attempts to recover from the error.

The issue with throw/catch is that throw acts like an unconditional goto to the catch part. Because of this, all of the state information that is available when throw is used that is not given to the exception object is lost. This becomes problematic if the code that catches the error wants to use some information about what happened when the error occurred in order to recover.

As an example, let’s say you are implementing a library which takes several files and parses a list of numbers from each one. One way to implement this library is as two functions. The first function, read-file, will read the contents of a single file and return a list of the results. The second, read-files, will take a list of files and return a list of the contents of each one. Here is what the code for those two functions might look like if they did not have any error handling:

(defun read-file (file)
  (with-open-file (in file :direction :input)
    (loop for line = (read-line in nil in)
          until (eq in line)
          collect (parse-integer line))))

(defun read-files (files)
  (loop for file in files
        collect (read-file file)))

To test the library you have two files. The first file contains the numbers 5, 10, 15, 20, 25 and the second contains 5, 10, 15, 20, a, 30, 40. In order to make sure your library handles errors properly, you decided to put a line which is just “a” in the second file. As it stands, parse-integer will signal an error when it comes across this line. To make testing the library easy, you have stored a list containing the pathnames of the two files in the variable *files*. Here is what happens when you try running the library on the two files:

(read-files *files*)


An error occurred due to the “a” in the second file. As the designer of the library you have to decide what should happen when a situation like this one comes up. Below are several different options you could choose from if your language only provided catch/throw.

Your first option is to just skip the entry that caused the error. To do this, you could use handler-case, Common Lisp’s version of catch:

(defun read-file (file)
  (with-open-file (in file :direction :input)
    (loop for line = (read-line in nil in)
          until (eq in line)
          when (handler-case (parse-integer line)
                 ;; C is the name being used to
                 ;; refer to the exception object.
                 (error (c)
                   (declare (ignore c))
          collect it)))

(read-files *files*)

=> ((5 10 15 20 25) (5 10 15 20 30 40))

Another option is to provide a dynamic variable1 which the user of the library can use to specify a value to be used in place of the malformed entry:

(defvar *malformed-value* nil)

(defun read-file (file)
  (with-open-file (in file :direction :input)
    (loop for line = (read-line in nil in)
          until (eq in line)
          when (handler-case (parse-integer line)
                 (error (c)
                   (declare (ignore c))
          collect it)))

(let ((*malformed-value* :malformed))
  (read-files *files*))

=> ((5 10 15 20 25) (5 10 15 20 :MALFORMED 30 40))

A third option is to have read-files catch the error and skip the entire file with the malformed entry:

(defun read-files (files)
  (loop for file in files
        when (handler-case (read-file file)
               (error (c)
                 (declare (ignore c))
        collect it))

(read-files *files*)

=> ((5 10 15 20 25))

Your last option is to let the user of the library handle the exception themselves:

(handler-case (read-files *files*)
  (error (c) (do-something)))

To the user, this last option is somewhat useful because it gives them some flexibility into how the error is handled. As mentioned above, the problem with doing this is that it becomes difficult for the user to properly recover from the error. If the user just wanted to skip the one corrupted file, there is no easy way to for them to do that due to the fact that by the time their error handling code is ran, execution would have left read-files. This means all of the state information, such as the remaining files that need to be read from, is completely lost by the time their code catches the exception.

Another problem with catch/throw is that of the four possible ways above you could handle the problem, you only get to choose one of them. Any one of them is in conflict with all of the others. Again, this is because throw acts like goto. Once you decide where you are jumping to, you have no control over what happens next. And, if you let the user handle the error themselves, they have no easy way to handle the error gracefully since all of the state information is lost.

This is where restarts come in. In Common Lisp, catch is provided as two separate pieces: handlers and restarts. A handler is bound by the user of the library in order to specify what should happen when an exception is thrown and a restart is defined by the library in order to provide a recovery option to the user. If you are using a language that supports restarts, you could implement the first three options above as restarts. Then when a user is using the library, they will get to select which of those restarts they want to have run when an error occurs. If they do not want to use any of the restarts, they can run their own code instead. Here is the code for the file reading library, but reimplemented to support three different restarts, one for each of the first three ways to handle errors.

(defun ask (string)
  (princ string *query-io*)
  (read *query-io*))

(defun read-file (file)
  (with-open-file (in file :direction :input)
    (loop for line = (read-line in nil in)
          until (eq in line)
          when (restart-case (parse-integer line)
                 (use-value (value)
                   :report "Use a new value."
                   :interactive (lambda ()
                                  (list (ask "Value: ")))
                 (skip-entry ()
                   :report "Skip the entry."
          collect it)))

(defun read-files (files)
  (loop for file in files
        when (restart-case (read-file file)
               (skip-file ()
                 :report "Skip the entire file."
        collect it))

;;; The three functions below are predefined
;;; handlers for the most common ways the user
;;; will interact with the restarts.
(defun skip-entry (c)
  (declare (ignore c))
  (invoke-restart 'skip-entry))

(defun skip-file  (c)
  (declare (ignore c))
  (invoke-restart 'skip-file))

(defun use-value-handler (value)
  (lambda (c)
    (declare (ignore c))
    (invoke-restart 'use-value value)))

A restart is defined with the macro restart-case, and invoked by the function invoke-restart. This is a bit of a simplification, but invoking a restart is effectively equivalent to jumping to the body of the restart from where the error was signaled. This means that all of the state stored on the stack before the restart was established is still available when the restart is invoked. This gives the user of the library much finer grained control over what happens when an error is thrown.

To specify what should happen, all the user needs to do is use the macro handler-bindHandler-bind takes an error type and a handler (which should be a function) to call when an error of that type is thrown. The handler can then call invoke-restart in order to invoke one of the restarts provided by the library. As part of the library, there is one handler per restart provided, since those are the most common kinds of handlers. Here is what happens when each of the handlers are used when running the library on the two test files:

(handler-bind ((error #'skip-entry))
  (read-files files*))

=> ((5 10 15 20 25) (5 10 15 20 30 40))

(handler-bind ((error #'skip-file))
  (read-files files*))

=> ((5 10 15 20 25))

(handler-bind ((error (use-value-handler 0)))
  (read-files files*))

=> ((5 10 15 20 25) (5 10 15 20 0 30 40))

The really cool thing about restarts is what happens when the user doesn’t handle the error. When this happens they will enter the Slime Debugger. From there they will be given a list of the restarts that are available to them and they will be able to invoke them as if the error had been handled in the first place! Here is what happens when a user doesn’t handle the error, and then invokes the skip-entry restart on the fly: (3)


What’s really cool about this is that this “interactive restarting” can use it to implement breakpoints! As I said in Part 1, Common Lisp provides breakpoints as a function “break” instead of as a feature of the editor. Here is code that could be used to implement break:

(defun break (&optional (format-control "Break")
              &rest format-arguments)
   (with-simple-restart (continue "Return from BREAK.")
     (let ((*debugger-hook* nil))
         (make-condition 'simple-condition
           :format-control   format-control
           :format-arguments format-arguments))))

The code for break works by signalling an error while providing a “continue” restart. This means that as soon as the function break is called, you will enter the debugger with a restart available which will continue normal execution. Exactly what a breakpoint actually is.

Restarts are another fantastic part of debugging Common Lisp. They give you better control over what happens when an error occurs. And, if your code doesn’t handle the error itself, you can still recover the process by using an interactive restart.

The post Debugging Lisp Part 4: Restarts appeared first on Macrology.

Didier VernaThe Return of Segfaults

· 23 days ago

I was watching the discussion between Gilad Bracha and Matthias Felleisen on gradual typing this afternoon (it's available on YouTube). This was the last event at the STOP workshop, part of ECOOP 2015 in Prague. I couldn't attend it because I was somewhere else (Curry On) at the time. The discussion is interesting, but if you go all the way, in the last 10 minutes or so, you will notice that Matthias seems to be completely obsessed with what he calls the "Return of the SegFaults".

Basically, the point is the following. Mathias dislikes the optional types in Common Lisp because it's opening the door to unsafety. Initially, any dynamic language has a sound type system (all type errors are caught; at run-time, yes, but they are caught). As soon as you introduce an optional type system ala Lisp, the compiler implementors are "pushed" to use the provided type information for optimization, hence weakening the type system and breaking soundness. It's the "return of segfauts".

Of course, I agree with that, at least on the principle. Yes, Common Lisp's weak, optional type system is an antiquated thing. However, it seems to me that Matthias is forgetting two important things on the practical level:

  1. by default in many implementations that I know, if not all of them, introducing type declarations doesn't actually break the soundness of the type system but leads to even more type checking. For example, (defun plus (a b) (+ a b)) works on every possible numerical value, but add (declare (type fixnum a b)) in there and it will suddenly stop working on anything else but integers. It's only if you require the compiler to optimize for speed at the expense of safety that you effectively weaken your type system.
  2. In practice, the risk of re-introducing segfaults in your application may be mitigated by the interactive aspect of the development (TDD made easier, simultaneous write / compile / run / test / debug phases etc.).

So my impression is that Matthias is largely exaggerating the problem, but I'm not really qualified to tell. That's why I would like to know from you guys, working with Lisp in the industry, writing large applications, lots of type annotations, and (declaim (optimize (speed 3) (safety 0) (debug 0)) (EDIT: that's exaggerated of course, I really mean breaking safety for performance reasons): how much of a problem the "return of the segfaults" really is in practice ?

As a side note, this reminds me of the dynamic vs. lexical scoping debate. Many people were and still are strongly opinionated against dynamic scoping by default. Of course, I too, at least in principle. But how dangerous dynamic scoping really is in practice (EDIT: I'm not talking about expressiveness, e.g. closures, here. Only unsafety.)? What I can tell you is that in the 15 years I was actively maintaining the XEmacs codebase, I may have run into name clashes due to dynamic scoping... twice.

LispjobsClojure/Clojurescript Web Developer and Junior Clojure Developer, Kira Systems, Toronto, Canada

· 23 days ago

Kira Systems has two positions available. Both of out of Toronto, but the first one could also be remote in North America:

Quicklisp newsAugust 2015 Quicklisp dist update now available

· 23 days ago

New projects:

  • binfix — BINFIX -- A powerful binary infix syntax for Common LISP. — GNU GPLv2
  • ceramic — Common Lisp web apps on the desktop — MIT
  • cl-bson — BSON encoder/decoder for Common Lisp. — LLGPL
  • cl-intbytes — Encode/decode any-base integers and byte arrays interchangeably. — LLGPL
  • cl-liballegro — Allegro game programming library bindings. — Unspecified
  • clml — Common Lisp Machine Learning Library — LLGPL
  • fred — Lisp Interface to Federal Reserve Economic Data (FRED®) — MIT
  • halftone — An image viewer using Qtools — Artistic
  • kenzo — A Symbolic Software for Effective Homology Computation by Francis Sergeraert — GPLv3
  • oe-encode — An implementation of the ENCODE() hash function from Progress OpenEdge. — CC0 1.0 Public Domain
  • tiff4cl — TIFF access primitives — LGPL

Updated projects: access, array-utils, basic-binary-ipc, bit-smasher, black-tie, buildapp, caveman, cl-ana, cl-ansi-text, cl-closure-template, cl-cookie, cl-coveralls, cl-ev, cl-gists, cl-gss, cl-i18n, cl-isaac, cl-launch, cl-marklogic, cl-mlep, cl-murmurhash, cl-oauth, cl-opengl, cl-opsresearch, cl-pdf, cl-poker-eval, cl-proj, cl-pslib, cl-pslib-barcode, cl-qprint, cl-rabbit, cl-rfc2047, cl-sl4a, cl-slug, cl-string-match, clack, clack-errors, clinch, clipper, closer-mop, clx, colleen, com.informatimago, common-doc, common-html, croatoan, datafly, declt, defclass-std, dexador, djula, docparser, drakma, dyna, esrap, esrap-liquid, external-program, fare-utils, fast-http, frpc, gendl, glyphs, hdf5-cffi, hh-aws, hu.dwim.util, integral, introspect-environment, iolib, jonathan, let-over-lambda, lisp-interface-library, lquery, lucerne, md5, mpc, ningle, perlre, plump, proc-parse, protobuf, prove, purl, qlot, qmynd, qt-libs, qtools, quickapp, quri, racer, s-protobuf, scalpl, sdl2kit, serapeum, simple-tasks, split-sequence, stumpwm, swap-bytes, sxql, terminfo, trivial-download, trivial-extract, trivial-irc, uiop, varjo, verbose, woo, wookie.

Removed projects: ch-image, mini-cas.

To get this update, use (ql:update-dist "quicklisp"). Enjoy!

LispjobsSenior Software Engineer, goCatch, Sydney, Australia

· 24 days ago

Dear Will,

goCatch is looking for a senior software engineer to work full time on
its core product, which is a real time tracking and dispatch system for
taxi services. Our offices are located in Sydney, Australia. We will not
consider telecommuting, however we may be able to assist a promising
candidate to relocate.

We are a small team who prize themselves on writing quality, readable,
maintainable code, and are looking for like-minded individuals.

The successful candidate will have knowledge of

* Clojure [or a Scheme or Common Lisp, and a willingness to learn]
* willingness to work closely with collaborators, including occasional pair-programming
* cloud hosted systems; deployment on AWS

And any of the following additional skills would be considered an asset:
* programming in a functional style
* knowledge of the clojure ecosystem. We
* RabbitMQ or another message broker
* REST architecture
* IOS development
* Android/Java development
* modern front end web technologies (Angular, React, etc.)

Applicants are encouraged to send us a resume with a cover letter explaining
they development philosophy and describing their ideal working environment.
Please forward offers of interest to Alain Picard (

goCatch is an equal opportunity employer.


Sydney, Australia

drmeisterTiming data comparing CClasp to C++, SBCL and Python

· 28 days ago

Work on CClasp (Clasp using Robert Strandh’s Cleavir compiler) is moving forward, here is some timing data that I generated comparing CClasp performance to C++, SBCL and Python.

NOTE: this test is a specific test of an algorithm that uses FIXNUM arithmetic. I have inlined simple FIXNUM arithmetic (+, -, <, =, >, and fixnump) and so these operations are fast. Code that uses other functions will run a lot slower until inlining is implemented more broadly.

I’m calculating the 78th Fibonacci number 10,000,000 times in each case. For these integer arithmetic heavy functions, CClasp performs pretty well (~4x slower than C++). Once type inference is added as well as a few other optimizations CClasp should be generating performant code.

Note: There are compiler settings (loop unrolling) where the C code runs even faster than SBCL, it’s just for this specific test, with the compiler settings below that SBCL comes out a little faster than C++. I don’t want to start an argument about the speed of SBCL vs C++ here, my point is that CClasp has come a long way from being hundreds of times slower than C++ to within a factor of 4.

Here is the C++ code, it converts the numbers back and forth from Common Lisp representations:

Integer_sp core_cxxFibn(Fixnum_sp reps, Fixnum_sp num) {
  long int freps = clasp_to_fixnum(reps);
  long int fnum = clasp_to_fixnum(num);
  long int p1, p2, z;
  for ( long int r = 0; r<freps; ++r ) {
    p1 = 1;
    p2 = 1;
    long int rnum = fnum - 2;
    for ( long int i=0; i<rnum; ++i ) {
      z = p1 + p2;
      p2 = p1;
      p1 = z;
  return Integer_O::create(z);

Here is the Common Lisp code:

(defun fibn (reps num)
  (declare (optimize speed (safety 0) (debug 0)))
  (let ((z 0))
    (declare (type (unsigned-byte 53) reps num z))
    (dotimes (r reps)
      (let* ((p1 1)
             (p2 1))
        (dotimes (i (- num 2))
          (setf z (+ p1 p2)
                p2 p1
                p1 z))))

Here is the Python code:

import time
def fibn(reps,num):
    for r in range(0,reps):
        p1 = 1
        p2 = 1
        rnum = num - 2
        for i in range(0,rnum):
            z = p1 + p2
            p2 = p1
            p1 = z
    return z
start = time.time()
res = fibn(10000000, 78)
end = time.time()
print( "Result = %f\n", res)
print( "elapsed time: %f seconds\n" % (end-start))

More details.

CClasp version is 0.3-test-10

It was compiled using settings:
“clang++” -x c++ -O3 -gdwarf-4 -g -Wgnu-array-member-paren-init -Wno-attributes -Wno-deprecated-register -Wno-unused-variable -ferror-limit=999 -fvisibility=default -isysroot /Applications/ -mmacosx-version-min=10.7 -std=c++11 -stdlib=libc++ -O3 -O3 -gdwarf-4 -g -O3 -Wno-inline -DBUILDING_CLASP -DCLASP_GIT_COMMIT=\”cf99526\” -DCLASP_VERSION=\”0.3-test-10\” -DCLBIND_DYNAMIC_LINK -DDEBUG_CL_SYMBOLS -DDEBUG_FLOW_CONTROL -DEXPAT -DINCLUDED_FROM_CLASP -DINHERITED_FROM_SRC -DNDEBUG -DPROGRAM_CANDO -DREADLINE -DTRACK_ALLOCATIONS -DUSE_BOEHM -DUSE_CLASP_DYNAMIC_CAST -DUSE_STATIC_ANALYZER_GLOBAL_SYMBOLS -D_ADDRESS_MODEL_64 -D_RELEASE_BUILD -D_TARGET_OS_DARWIN -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I”../../../../include” -I”../../../../projects/cando/include” -I”../../../../src” -I”../../include” -I”../../src/cffi” -I”../../src/core” -I”../../src/gctools” -I”../../src/llvmo” -I”../../src/main” -I”../../src/serveEvent” -I”../../src/sockets” -I”/Users/meister/Development/externals-clasp/build/common/include” -I”/Users/meister/Development/externals-clasp/build/release/include” -c -o “../../src/main/bin/boehm/cando/clang-darwin-4.2.1/release/link-static/main.o” “../../src/main/”

The C-code is embedded within Clasp and is thus compiled with the same settings.

The Clang version is 3.6.1

The Python version is 2.7.6. I ran the python code using: python

The SBCL version is: SBCL 1.2.11

These were run on a MacBook Pro (Retina, 15-inch, Early 2013)

Stelian IonescuNative TravisCI Support for Common Lisp

· 31 days ago

Being used to Continuous Integration at work, I wanted to use it for my Lisp projects too. Looking around, the choice was pretty easy: TravisCI is a very nice platform developed by a company in Berlin, which offers free testing for open-source projects hosted at Github.

I saw that Luís Oliveira preceded me, so I followed the instructions at cl-travis and created a .travis.yml for all my libraries. Cl-travis contains a script that is run in the setup phase of the test and relies on CIM to provide a wrapper for common command line parameters of Lisp compilers. For the task at hand CIM works very well. Unfortunately, cl-travis has a few shortcomings:

  • it hard-codes the implementation versions, so you can't test on multiple versions, e.g. the one you use at work for internal projects, and the latest one for the benefit of open-source developers
  • it has to install a few system packages required for running the Lisp implementations, which means it forces the test to use the old infrastructure based on VMs that are setup for every single test, taking a few minutes to boot. If we can avoid installing packages from within the .travis.yml file, we can use the new infrastructure based on light-weight containers which are spawn almost instantaneously
  • it lacks integration with the TravisCI UI, e.g. to distinguish between the implementation used for a test run and proper build parameters

All that works, but there could be better because Travis allows adding community support for a language, for which there is an excellent documentation. In short, a group of at least three people are required to guarantee support, given that Travis generally updates the base image every three months. Extensions must be written in Ruby(for the core build infrastructure) and CoffeeScript(for the UI). I'm looking for help so if you're interested I've opened a mailing list and a Github project.

Update: Fernando Boretti also blogged here about using cl-travis

Eugene ZaikonnovThe simplest bitmap format ever

· 34 days ago

So here's one fine, terse, human readable (!) image format you can roll quickly in a squeeze. It is also understood by nearly every web browser and image viewer out there. It's Netpbm, the underdog of image processing world.

There are three subformats, for binary, grayscale and RGB images. Each comes in human-readable ASCII and binary version. Here's a sample for ASCII grayscale borrowed from pgm manpage:

       # feep.pgm
       24 7
       0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
       0  3  3  3  3  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15 15 15 15  0
       0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0 15  0
       0  3  3  3  0  0  0  7  7  7  0  0  0 11 11 11  0  0  0 15 15 15 15  0
       0  3  0  0  0  0  0  7  0  0  0  0  0 11  0  0  0  0  0 15  0  0  0  0
       0  3  0  0  0  0  0  7  7  7  7  0  0 11 11 11 11  0  0 15  0  0  0  0
       0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

The header is the format magic (P2 is ASCII grayscale), arbitraty comment lines starting with '#', image dimensions and the maximum grayscale value. The latter is rather nice property as it allows for flexible grayscales. The header is followed by ASCII image value payload, formatted according to the header specs.

Here's a short Common Lisp code example.

(defun image-to-pgm (image filename)
  (with-open-file (f filename :direction :output
                      :if-exists :overwrite :if-does-not-exist :create)
    (let ((y (first (array-dimensions image)))
          (x (second (array-dimensions image))))
      (format f "P2~%~D ~D~%255" y x)
      (loop for i from 0 below y do
       (terpri f)
       (loop for j from 0 below x do
        (format f "~D " (- 255 (aref image i j))))))))

Now the impracticality of it in every day use is clear. It is wasteful with bytes (although it should compress just as well as its binary counterpart). The spec also limits the ASCII version to 70 characters per line, although some parsers would accept longer ones. However it is great little format when you need to viusalize smaller things but don't feel like using an image format library.

Michael MalisDebugging Lisp Part 3: Redefining Classes

· 36 days ago

This is part 3 of Debugging Common Lisp. If you haven’t read either of the previous parts, you can find part 1 here, and part 2 here.

The Common Lisp Object System (CLOS) is pretty powerful. It gives you multiple inheritance, multiple dispatch, and many different ways to extend the behavior of methods. Underneath, most implementations use the Metaobject Protocol (MOP), a way of defining CLOS in terms of itself. As part of the MOP, classes are implemented as objects with several instance variables. Among those are variables that hold the class’s name, its superclasses, and a list of the class’s own instance variables. If you don’t believe me, take the point class from the previous post:

(defclass point ()
  ((x :accessor point-x :initarg :x :initform 0)
   (y :accessor point-y :initarg :y :initform 0)))

And use the Slime Inspector to inspect the point class object, which can be obtained by calling find-class:


The advantage of using the MOP is that it makes it possible to fine tune the behavior of CLOS by using ordinary object-oriented programming. A great example of this is the filtered-functions library which adds arbitrary predicate based dispatch to CLOS. But enough about the MOP.1 In this post I’m going to talk about one tiny piece of CLOS, update-instance-for-redefined-class.

Update-instance-for-redefined-class is a method which is called whenever a class is redefined (at runtime). By overriding it, you can customize what exactly happens at that point in time. For example, let’s say you are using the above point class to represent complex numbers for some sort of simulation. As part of the simulation, you have a point object saved inside of the *location* variable: (1)


After profiling the simulation, you find that one of the bottlenecks is complex multiplication. Since multiplication of complex numbers is much more efficient when they are represented in polar form, you decide that you want to change the implementation of the point class from Cartesian to polar coordinates. To do that (at runtime), all you need to do is run the following code:

(defmethod update-instance-for-redefined-class :before
     ((pos point) added deleted plist &key)
  (let ((x (getf plist 'x))
        (y (getf plist 'y)))
    (setf (point-rho pos) (sqrt (+ (* x x) (* y y)))
          (point-theta pos) (atan y x))))

(defclass point ()
  ((rho :initform 0 :accessor point-rho)
   (theta :initform 0 :accessor point-theta)))

(defmethod point-x ((pos point))
  (with-slots (rho theta) pos (* rho (cos theta))))

(defmethod point-y ((pos point))
  (with-slots (rho theta) pos (* rho (sin theta))))

Basically, the code extends update-instance-for-redefined-class to calculate the values of rho and theta for the polar implementation in terms of the variables x and y from the Cartesian one. After extending update-instance-for-redefined-class the code then redefines the class, causing all of the existing instances to be changed over to the new implementation.2 Finally, two methods are defined, point-x and point-y, which preserve the interface for the point class.3 After running the code and then inspecting the contents of *location*, you should see: (2)


Even though the object inside of *location* is still the same object, it is now implemented using polar coordinates! To make sure that it was converted from Cartesian to polar correctly, you decide to call point-x on the object to check that the x-coordinate is still the same:

Amazingly, all of the code continues to work even though the implementation of an entire class was completely changed. So anytime you want to change the implementation of a class that is part of a service that needs to be up 24/7 and just happens to be written in Common Lisp, remember to use update-instance-for-redefined-class.

The post Debugging Lisp Part 3: Redefining Classes appeared first on Macrology.

LispjobsTwo positions at SPARQL Engine and Database Storage programmer (Oakland, CA)

· 38 days ago

Franz, Inc., a medium size software company in Oakland, CA (2 blocks from BART) is looking for a Software Developer to join their AllegroGraph group.

Links to the two positions:

Michael MalisDebugging Lisp Part 2: Inspecting

· 44 days ago

This is part 2 of Debugging Lisp. If you haven’t read part 1, you can find it here.

In this post I am going to discuss another tool used for debugging Common Lisp – the Slime Inspector. The Slime inspector makes it possible to manipulate objects directly from the repl. You can do many different things with it, including clicking on objects to look at their contents and being able to copy and paste objects in order to reuse them in future function calls.1 Let’s say you have the following point class:

(defclass point ()
  ((x :accessor point-x :initarg :x :initform 0)
   (y :accessor point-y :initarg :y :initform 0)))

If you were to make an instance of the above class:

(make-instance 'point :x 10 :y 20)

You can then right click on it and click on the “inspect” option, or just use the Emacs shortcut “C-c C-v TAB” to peek inside the object: (5)


This will show you the current values of all of the instance variables of the object. Not only can you look at the object’s instance variables, you can modify them as well. Note that the power comes from being able to do all of this from within the debugger at runtime. (7)


To make sure that the value of that object was actually changed, you can copy and paste the point object and then call the point-x function on it. (5)


One more really cool tool that hooks into the Inspector is the Slime Trace Dialog. The Slime Trace Dialog is like ordinary trace, but it also allows for inspection on the objects that were passed to or returned from the traced functions. For example, let’s say you are writing a tail call optimized function, sum, that sums all of the numbers in a list.

(defun sum (xs &optional (acc 0))
  (if (null xs)
      (sum (cdr xs) (+ (car xs) acc))))

(sum '(1 2 3))
=> 6

You can toggle the use the Slime Trace Dialog to trace sum by typing the shortcut “C-c M-t” and then typing in the name of function, “sum". After tracing it and running the code, you can press “C-c T” to enter the interactive Trace Dialog buffer. From there you can press “G” to refresh it and obtain the most recent trace. (4)


The trace will look like the output from ordinary trace, except it will have some addition goodies. As I said above you can inspect all of the arguments and return values. You can also hide/show branches of the trace tree in order to make it easier to find what you are looking for. (8)


The Slime Trace Dialog is invaluable when you have code which is passing lots of objects around and you aren’t exactly sure what the value of each variable in each object is. You can just use the Slime Trace Dialog and have it keep track of all of the information for you.

All in all, the Slime Inspector is another amazing part of the Common Lisp debugging tool set. It comes in handy when the program crashes and you are unaware of the current state of the program. When combined with the rest of the features for debugging Common Lisp, the Slime Inspector is just incredible.

The post Debugging Lisp Part 2: Inspecting appeared first on Macrology.

Zach BeaneCeramic: a new CL application style

· 44 days ago

Ceramic by Fernando Borretti is an interesting project that takes Common Lisp web applications and makes them into desktop applications. There’s some discussion about it on Hacker News and reddit.

Didier VernaDeclt 2.0 is out -- IMPORTANT

· 46 days ago

Declt 2.0 "Kathryn Janeway" is out. This release doesn't contain any change in functionality, yet deserves a major version upgrade since it contains 3 important changes: an infrastructure revamp (along the lines of what Clon endured not so long ago), a license switch from the GNU GPL to a BSD one, and finally a system / package name change. The prefix is now net.didierverna instead of com.dvlsoft. Do I need to apologize for this again? :-)

Find it at the usual place...

Quicklisp newsJuly 2015 Quicklisp dist update now available

· 48 days ago
This Quicklisp update is supported by my employer, Clozure Associates. If you need commercial support for Quicklisp, or any other Common Lisp programming needs, it's available via Clozure Associates.
New projects:

  • check-it — A randomized property-based testing tool for Common Lisp. — LLGPL
  • cl-gists — Gists API Wrapper for Common Lisp. — MIT
  • cl-git — A CFFI wrapper of libgit2. — Lisp-LGPL
  • cl-opsresearch — Common Lisp library for Operations Research. — GPL3
  • cl-scripting — Utilities to help in writing scripts in CL — MIT
  • hu.dwim.graphviz — Graphviz layouting using CFFI bindings. — public domain
  • hu.dwim.presentation — A component based GUI framework with a backend to present it using HTML and JavaScript. — public domain
  • jp-numeral — A printer for Japanese numerals. — MIT
  • quickapp — A utility library to automate much of the app creation process — Modified BSD License
  • simple-tasks — A very simple task scheduling framework. — Artistic
  • terminfo — Terminfo database front-end. — copyrights
  • trivial-main-thread — Compatibility library to run things in the main thread. — Artistic
  • trivialib.type-unify — unifies a polimorphic type specifier with type variables against actual type specifiers — LLGPL
Updated projects: arrow-macros, binascii, birch, bit-smasher, buffalo, burgled-batteries.syntax, caveman, cerberus, cl-ana, cl-ansi-term, cl-async, cl-charms, cl-clon, cl-coveralls, cl-dbi, cl-freetype2, cl-growl, cl-isaac, cl-ledger, cl-libssh2, cl-libuv, cl-marklogic, cl-mongo-id, cl-netstring-plus, cl-olefs, cl-rabbit, cl-readline, cl-reexport, cl-rethinkdb, cl-rss, cl-sdl2, cl-slug, cl-spark, cl-string-match, cl-uglify-js, cl-voxelize, cl-yaclyaml, clack, clfswm, closer-mop, coleslaw, colleen, com.informatimago, command-line-arguments, common-doc-plump, commonqt, croatoan, dbus, declt, defclass-std, dexador, dissect, djula, docparser, drakma, dyna, eazy-gnuplot, fare-csv, fast-http, flexi-streams, frpc, generic-sequences, glass, glyphs, hemlock, hu.dwim.common, hu.dwim.def, hu.dwim.logger, hu.dwim.uri, hu.dwim.util, hu.dwim.web-server, hunchentoot, immutable-struct, integral, intel-hex, iolib, jonathan, jsown, lack, legion, let-over-lambda, lisp-interface-library, lisp-invocation, lisp-unit2, lucerne, madeira-port, marching-cubes, mathkit, mcclim, media-types, mexpr, mk-string-metrics, nibbles, ningle, optima, osicat, perlre, pileup, postmodern, pounds, pp-toml, priority-queue, prove, qlot, qmynd, qt-libs, qtools, quadtree, quicklisp-slime-helper, quri, rutils, sb-cga, screamer, scriba, serapeum, slime, smackjack, staple, stumpwm, sxql, transparent-wrap, trivial-download, trivial-features, trivial-lazy, trivial-signal, trivial-update, type-r, uiop, unix-opts, varjo, verbose, vgplot, weft, woo, wookie, workout-timer, x.fdatatypes, x.let-star, yaclml.

Michael MalisDebugging Lisp Part 1: Recompilation

· 51 days ago

This post is the start of a series on how to debug Common Lisp code, specifically with Emacs, Slime, and SBCL. If you do not understand Common Lisp, you should still be able to follow along and recognize just how powerful the facilities provided by the Common Lisp debugger are. Nathan Marz asked me to write these posts since he thought many of the tools for debugging Common Lisp were pretty cool.

The first thing you need to do in order to get started debugging Common Lisp is to set your Lisp’s optimization qualities. Optimization qualities are basically a group of settings which allow you to specify what the compiler should optimize for. These qualities include speed, space, compilation speed, safety, and debugging. If you do not run the code below, which tells the compiler to optimize for debugging, almost none of the examples in this post will work.

CL-USER> (declaim (optimize (debug 3)))

CL-USER> (your-program)

With the compiler optimized for debugging, it becomes possible to do pretty much everything at runtime. This post will show you how Tom, an experienced Lisp developer would debug and patch a buggy function at runtime. Let’s say that Tom has the following code which implements the well known Fibonacci function:

(defun fib (n)
  (if (<= 0 n 1)
      (/ 1 0)
      (+ (fib (- n 1))
         (fib (- n 2)))))

There’s just one problem, the code isn’t correct! Instead of returning n in the base case, the code winds up dividing by zero. When Tom tries to calculate the tenth Fibonacci with this code, a debugger window pops up because an error was signaled.


Realizing that he has entered the debugger, Tom wonders what has gone wrong. In order to find the bug, Tom decides to insert a breakpoint into the function.1 In Common Lisp, breakpoints are implemented as a function called ‘break'.2 To insert his breakpoint, Tom adds a call to break at the beginning of fib. After adding the breakpoint, Tom then puts his cursor next to one of the frames and hits the ‘r’ key in order to restart it. In this case, Tom decided to restart the frame where n was three.


By restarting the frame, Tom basically traveled back in time to the beginning of the frame he restarted. After restarting the frame, the debugger immediately hits the breakpoint Tom had just added. From there Tom steps through the code by hitting the ‘s’ key. He eventually realizes that the base case is implemented incorrectly and that that is why he received the error. (2)


After finding the source of the problem, similar to how he had previously inserted the breakpoint, Tom patches the code. He replaces the base case with n and removes the breakpoint he had previously inserted. (3)


After recompiling the code, Tom once again restarts one of the frames. Since he was previously stepping through code, the debugger starts stepping through the frame Tom decided to restart. Tom just taps the ‘0’  (zero) key in order to invoke the step-continue restart3 and continue normal execution. Because Tom restarted a frame which occurred before the bug, and now that the bug is gone, the code runs as if there had never a bug in the first place! (3)


Let’s recap what happened. After the code signaled an error, Tom found himself in the debugger. Tom was able to insert a breakpoint and poke around until he found the source of the problem. After finding the problem, Tom patched the code and restarted the process from a point before it had signaled an error. Because Tom had corrected the code, after he restarted the frame, it acted as if nothing had ever gone wrong!

The ability to recompile code at runtime is just one of the many incredible features provided by Common Lisp. Next time, I’m going to talk about the Slime inspector, which makes it possible to look into and modify objects from within debugger.

The post Debugging Lisp Part 1: Recompilation appeared first on Macrology.

Quicklisp newsJune 2015 download stats

· 52 days ago

Here are the top 100 downloads for June, 2015:

8413 alexandria
5803 babel
5222 cffi
5152 trivial-features
4926 cl-ppcre
4621 bordeaux-threads
4308 trivial-gray-streams
4208 closer-mop
4112 usocket
4068 flexi-streams
3891 trivial-garbage
3815 cl+ssl
3727 cl-fad
3597 split-sequence
3591 anaphora
3510 iterate
3274 cl-base64
3200 chunga
3141 nibbles
3136 chipz
3083 puri
2992 drakma
2678 ironclad
2521 named-readtables
2407 local-time
2391 let-plus
2256 cl-colors
2231 md5
2152 slime
2148 trivial-backtrace
2089 cl-ansi-text
1984 prove
1769 metabang-bind
1574 cl-unicode
1512 optima
1487 hunchentoot
1455 cl-interpol
1392 cl-utilities
1328 rfc2388
1301 cl-annot
1215 quri
1178 trivial-types
1090 cl-syntax
1080 fast-io
1059 static-vectors
1038 salza2
1011 trivial-indent
1000 cl-json
966 plump
943 parse-number
941 ieee-floats
933 trivial-utf-8
918 array-utils
841 fiveam
802 postmodern
778 proc-parse
772 lparallel
759 stefil
751 quicklisp-slime-helper
741 fast-http
741 xsubseq
740 clss
734 lquery
724 clack
695 jsown
693 lack
677 cl-dbi
676 jonathan
669 closure-common
666 osicat
658 cl-html-parse
658 cl-sqlite
646 asdf-system-connections
642 cxml
634 uuid
628 esrap
625 yason
619 symbol-munger
611 fare-utils
608 lisp-unit
602 cl-who
595 external-program
585 cl-csv
573 http-body
572 metatilities-base
569 cl-containers
555 trivial-mimes
545 fare-quasiquote
538 hu.dwim.asdf
524 cl-marshal
520 log4cl
511 zpng
511 command-line-arguments
490 cl-log
478 html-template
476 function-cache
471 cl-yacc
469 trivial-shell
427 circular-streams
422 cl-emb

Zach BeaneQuicklisp: beyond beta

· 57 days ago

I gave a talk at ELS 2015 in London in April about the past, present, and future of Quicklisp. The "future" part detailed several things I'd like to accomplish before removing the beta label from Quicklisp.

The slides and script of the talk are available on github. But since there are over a hundred slides and about twenty pages of script, I thought I'd summarize things in this post.

First, what's Quicklisp for, anyway? The slogan I put in the talk is: Make it easy to confidently build on the work of others. (Also, work on as many Common Lisps on as many platforms as possible.) 

Quicklisp achieves part of that already. It runs well on almost all Common Lisp implementations on all platforms. It's easy to install, use, and update. Things are tested together so everything usually works. But if something breaks on update, you can revert to a previous working version. And with those features you can build on hundreds of libraries already.

If it can do all that, why not drop the "beta" already? There are still a number of things that I want Quicklisp to do before I'm ready to say "Here, this is what I had in mind from the start."

First, I'd like to improve the confidence in the code you download and run. By adding HTTPS, signature checking, and checksum validation, you can be sure that there is nobody intercepting and modifying the software provided by Quicklisp. The signature and archive integrity checks must be made complete and automatic to have the best results.

Second, I'd like to add comprehensive user and developer documentation. For users, that means being able to learn each command, feature, and behavior of Quicklisp, to be able to use it to its fullest. For developers, that means being able to build your own solutions on a Quicklisp foundation without starting from scratch.

Third, I'd like to make it easy to find the project that does what you need, evaluate its quality and popularity, and find out if its license is compatible with your goals. If you want to make changes to a project, I want it to be easy to get the original source of a project and send fixes or improvements to the upstream maintainer.

Fourth, I'd like to make it easy to hook into the archive-fetching component of Quicklisp in a way that makes it easy to support additional integrity checks, support local development policies, and add local mirrors or caches for Quicklisp software.

These changes and improvements will take time. When they're done, I'll be happy to drop "beta" from Quicklisp.

Michael MalisMultiple-value-bind

· 58 days ago

Common Lisp is a pretty unique language. One of the many features that makes Common Lisp such an awesome language is multiple values. Yes, you read right. In Common Lisp it is possible for a function to return more than a single value. One example of a function that takes advantage of multiple values is floor. Floor takes a number as its argument and returns two values, whatever was passed in rounded down and the remainder.

(floor 3.5)

When you use floor in the manner above, you get two values back, 3 as the first return value, and 0.5 as the second. What’s really cool is that the values besides the first are completely ignored unless you explicitly ask for them.1 This means you can pretend that floor returns only a single value as long as you don’t need the other ones. Notice how in the following example, the + function is not aware of the second value returned by floor:

(+ (floor 3.5) 10)
=> 13

Now you may be wondering, “How can I obtain other values besides the first one?”. Well, there are several macros for doing that, the main one being multiple-value-bind. To use multiple-value-bind, you specify a list of the variables you want to bind each value to, followed by the expression that will return multiple values. Let’s say you want to multiply the two values returned by floor together. Here is how you would do that with multiple-value-bind:

(multiple-value-bind (val remainder) (floor 3.5)
  (* val remainder))
=> 1.5

It is also easy to create your own function that returns multiple values. All you need to do is pass each value you want to return to the values function. Below is a function which returns both twice its argument and three times its argument:

(defun multiples (x)
  (values (* 2 x) (* 3 x)))

(multiples 10)

There is just one more thing you need to know about multiple values. If the last call of a function is to another that returns multiple values, the first function will return all of the values the second one returns. If you were to write a function that doubles its argument and then uses floor to round it down, that function will return both values that are returned by floor.

(defun double-and-round-down (x)
  (floor (* 2 x)))

(double-and-round-down 5.25)

This behavior may or may not be desired. The standard way to make sure your function only returns a single value is to wrap the function that returns multiple values with a call to valuesValues will pay attention only to the first value and will return just that and nothing else.

(defun double-and-round-down (x)
  (values (floor (* 2 x))))

(double-and-round-down 5.25)
=> 10

And that’s all you need to know to work with multiple values!

The post Multiple-value-bind appeared first on Macrology.

Didier VernaDeclt 1.1 is released

· 60 days ago


as promised last week, I've just released a new version of Declt, my reference manual generator for ASDF systems. This new version (1.1) is now able to document Clon again (the documentation of which has been updated on the website).

New in this release:

  • Declt now properly handles and documents complex system and component dependencies, such as :feature :require and :version statements,
  • Declt also documents a system's :if-feature if any.

But the most important addition is the ability to document several ASDF systems in the same reference manual. More precisely, Declt now documents not only the main system but also all its subsystems. A subsystem is defined as a system on which the main one depends on in any way, and which is also part of the same distribution (under the same directory tree). Declt also understands multiple system definitions from the same .asd file.


For older items, see the Planet Lisp Archives.

Last updated: 2015-08-27 19:18