Lazily cleaning up....

I just cleaned up a bit the CLAZY library. Things are tidier in the implementation, obvious bugs have been swatted away and the web site is more informative (although by no means complete). A big thank goes to Theam Yong Chew, Joshua Taylor and Raffael Cavallaro for ideas and testing. Some more extensions are in the pipeline...

(cheers)

---

Feeling lazy....

In my bouts of "other higher programming language envy" (no SLDJs), I wandered the realm of lazy evaluation. The results are being slowly collected in the CLAZY library. In principle it is not difficult to write up a lazy library in Common Lisp. What is difficult is the balancing act you want to achieve in making your library work nicely with and within the language. My choice has been to concentrate on the function call point by providing an explicit extra call operator patterned after funcall. The result is lazy:call.

This has a number of nice consequences w.r.t. re-defining each of your lazy functions as macros (which is another implementation strategy). The foremost is that lazy calls (which, let's remember, are the exception and not the rule in a strict language like Common Lisp) are clearly marked. Let's see a simple example. A function which chooses the first of its non-null 4 arguments and returns 0, 1, 2, or 3. A call in strict Common Lisp could be:

cl-prompt> (choose4 nil nil t t)
2

Using CLAZY, the same function called lazily would appear in expressions like the following ones.

cl-prompt> (lazy:call #'choose4 nil t nil t)
1

cl-prompt> (lazy:call #'choose4 nil nil t (loop (print 42)))
2

The lazy call is clearly marked. An alternative would be to define special syntax to mark lazy calls. Something like:

cl-prompt> {choose4 nil nil t (loop (print 42))}
2

But I don't like to highjack parenthesis syntax (more on this subject later; note that there are no reader macros defined in CLAZY). If I need to improve my self-esteem I can always start progamming in Perl. Besides, given the CLAZY implementation, it is easy to do something like the following.

cl-prompt> (lazy:slacking
              (choose4 nil nil t (loop (print 42))))
2

cl-prompt> (lazy:lazily
              (choose4 nil t (loop (print 42)) t))
1

slacking and lazily are block-like macros (they do expand into a block) and do exactly the same thing: all lazy functions are lazy:called within the scope.

How is the choose4 function written? Like this:

(deflazy choose4 (e0 e1 e2 e3)
   (or e0 e1 e2 e3))

The deflazy macro defines both strict and lazy versions of a function. The def-lazy-function macro defines only the lazy version, which allows you to write

(def-lazy-function cons (car cdr) ...) ; You don't want to know... yet.

So, where does this lead us? To a nice Haskellesque library, where you can say (assume you are using the right packages).

cl-prompt> (take 4 (distinct (repeatedly 'random 64)))
(3 45 92 12)

How does this work? First of all, this last bit came out of a huge thread on C.L.L.... Second, I am too lazy now to tell you. Just hang around and wait.

(cheers)

European Lisp Symposium 2009 in Milan, Italy

As noted elsewhere, I am the local organizing chair of the 2nd European Lisp Symposium (ELS2009) in Milan, Italy.  Registration will be open soon.

(cheers)

Naming packages...

In the years I developed a style of package naming conventions.  It is heavily influenced by the Java hierarchical packages (and, let's remember, there are CL implementations that support hierarchical packages out there).  The style leverages CL nicknames to achieve another interesting effect, which people may find useful: namely, it can alert the developer of different library implementations being loaded in the CL runtime.

Suppose I started working on a new library/system/application which I want to call CLAMP (it has been in the works for ages). The name is simple enough, so I may start writing something like

(defpackage "CLAMP" (:use "CL") ...
 (:export "MAKE-CLAMP" ...))

(Note that I prefer to use strings for names in packages; you may use keywords, which have some drawbacks or uninterned symbols like #:clamp, but I'll comment on them in another post.)

Now, the name CLAMP isn't particularly distinctive, so you may (it's a big "may") end up with clobbering your package space if you load in your running CL another CLAMP package coming from elsewhere.

Since I learnt the Java lesson, I decide to rename my package in a more unique way as:

(defpackage "IT.UNIMIB.DISCO.MA.CL.CLAMP" (:use "CL") ...
 (:nicknames "CLAMP")
 (:export "MAKE-CLAMP" ...))

The new package name IT.UNIMIB.DISCO.MA.CL.CLAMP is rather unwieldy, so I added a nice nickname, CLAMP, which is what I wanted to use as the advertised name of my library. These choices have a few - at first seemingly fortuitous, but subsequently intended - consequences.

First of all, suppose that I have a different (older) version of my library floating around. Suppose also that in this version I have a terribly inefficient implementation of MAKE-CLAMP. My different version lives in a package named EDU.NYU.CS.MARCO.COMMON-LISP.CLAMP which also has the CLAMP nickname. When I try, willingly or inadvertently, to load both packages in the CL runtime, an error is signalled (*), thus alerting me of a naming conflict, which, in this case would also lead to more inefficient code.

So my recipe for naming packages is the following.

• Choose a unique enough package name, maybe following the Java hierarchical scheme.
• Add the advertised name of your package (or library) as a nickname.

(cheers)

---

(*) Most implementations I know of do signal a package-error. However, the ANSI spec is silent on the subject.

Here I am....

Recently I read somewhere that there are so many blogs that nobody has the time to read any of them.  So, if you are here chances are you have not started blogging yourself....

This is a blog about the cult I follow (or the minority I belong to, to paraphrase film director Nanni Moretti) and about little bits and pieces of code I write while I should be doing something else.  I.e., this is a blog about Lisp (Common Lisp in particular) and other programming issues I find interesting.

'(cheers)

--

Marco