ELS 2009 tomorrow

Here it is. Tomorrow there will be the reception for the opening of the 2nd European Lisp Symposium 2009 in Milan (www.european-lisp-symposium.org) I look forward to see many of you here in Milan.

---

(cheers)

CL-UNIFICATION does regexps (thanks to Edi Weitz)

I have been working for some time on the CL-UNIFICATION library. Somehow, "unification" and "parsing" are related but not quite (I bet the literature on the topic is huge). In an afternoon of the Easter vacation, I decided to take the easy way out of extending CL-UNIFICATION with some "parsing" functionality: I just added Edi Weitz's wonderful CL-PPCRE library. Edis' library has a very simple and intuitive interface which made the integration a SMOP! The result is the following. Now you can write the following (assuming all the packages are USEed):

(unify #T(regexp "a(b+)c(d+)" (?bs ?ds)) "abbbbcddd")

The call will produce an environment where ?BS is bound to "bbbb" and ?DS is bound to "ddd". Here is a full transcript.

CL-USER 3 > (in-package "UNIFY")
#<The CL.EXT.DACF.UNIFICATION package, 326/512 internal, 20/64 external>

UNIFY 4 > (unify #T(regexp "a(b+)c(d+)" (?bs ?ds)) "abbbbcddd")
#<UNIFY ENVIRONMENT: 1 frame 200BC147>

UNIFY 5 > (v? '?bs *)
"bbbb"
T

UNIFY 6 > (v? '?ds **)
"ddd"
T

Of course, the other matching operations work as expected.

UNIFY 9 > (match-case ("abbbbcdd")
                      (#T(regexp "a(b+)c(d+)" (?bs ?ds)) (concatenate 'string ?ds ?bs))
                      (t "It did not work!"))
"ddbbbb"

I.e., there is an interface to get to the actual regexp groups (beyond those available directly in CL-PPCRE). Maybe the syntax of the regexp unification templates could be made even more CL-PPCRE-like by exploiting "named registers", but, for the time being, the above is the best way to use it.

---

(cheers)

Maybe a bug? Some considerations.

Hello,

I just bumped into this while trying to load MEL-BASE into LW. The library has a file 'environment.lisp' which contains the following code.

#+openmcl
(defun gethostname ()
  "Returns the hostname"
  (ccl::%stack-block ((resultbuf 256))  
    (if (zerop (#_gethostname resultbuf 256))
      (ccl::%get-cstring resultbuf)
      (error "gethostname() failed."))))

As we know, OpenMCL, its predecessors, and its successors, define #_ as areader macro to call up system functions.

Now, LW (M 5.x) barfs on this, because it tries to READ the DEFUN in order to discard it.

I do not know if this is a bug or not (I have not checked), but it reinforced my preference for code organization, where I relegate implementation dependencies in separate files. I.e., I do not write a file like 'foo.lisp' and pepper it with a lot of #+, #-. I would relegate such system dependencies in a ccl.lisp (or a cmucl.lisp) file, and I would conditionally include the file in the .asd or .system file. This way I feel I have more control over system dependencies, and I do not incur in snag like the #_ one.

---

(cheers)

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