(within parens...)

European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012

2011-11-17T08:06:00.000-08:00

Site: http://european-lisp-symposium.org

The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We encourage everyone interested in Lisp to participate.

The main theme of the 2012 European Lisp Conference is "Interoperabilty: Systems, Libraries, Workflows". Lisp based and functional-languages based systems have grown a variety of solutions to become more and more integrated with the wider world of Information and Communication Technologies in current use. There are several dimensions to the scope of the solutions proposed, ranging from "embedding" of interpreters in C-based systems, to the development of abstractions levels that facilitate the expression of complex context dependent tasks, to the construction of exchange formats handling libraries, to the construction of theorem-provers for the "Semantic Web". The European Lisp Symposium 2012 solicits the submission of papers with this specific theme in mind, alongside the more traditional tracks which have appeared in the past editions.

We invite submissions in the following forms:

Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways.
Demonstrations: Abstracts of up to 4 pages for demonstrations of tools, libraries, and applications.
Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes.
Lightning talks: Abstracts of up to one page for talks to last for no more than 5 minutes.

All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998.

Important dates:

Jan 31st 2012: submission deadline
Feb 21st 2012: acceptance results
April 30th, 2012 Conference opens

Program Commitee:

Chair:
Marco Antoniotti, Università degli Studi di Milano Bicocca, Milan, ITALY

Local organizers:

Damir Ćavar, Eastern Michigan University
Franjo Pehar, University of Zadar
Damir Kero, University of Zadar

Members:

Giuseppe Attardi, Università degli Studi di Pisa, Pisa, ITALY
Pascal Costanza, Intel, Bruxelles, BELGIUM
Marc Feeley, Université de Montreal, Montreal, CANADA
Scott McKay, Google, U.S.A.
Kent Pitman, Hypermeta, U.S.A.
Christophe Rhodes, Department of Computing, Goldsmiths, University of London, London, UNITED KINGDOM
Robert Strandh, LABRI, Université de Bordeaux, Bordaux, FRANCE
Didier Verna, EPITA / LRDE, FRANCE

Mokum ECML 2011

2011-10-23T05:50:00.000-07:00

I am in Amsterdam for the ECLM 2011 and I must say that I have a distinctive feeling that the CL world is somehow doing very well. The meeting (as many of the readers know) is by invitation and the people presenting are from actual companies. The presentations have given me a sense of solidity of the companies represented, which, in the very words of the people presenting their work, is a reflection of the goodness of the choices made both of "problem" and "technologies": Common Lisp always being in key nodes of the implementation. Many thanks to Edi Weitz and Arthur Lemmens for organizing the meeting.

(cheers)

CL-UNIFICATION system and package names aligned.

2011-06-16T02:12:00.000-07:00

NS rightly complains here about system and package names for CL-UNIFICATION. I fixed the problem in CVS (it should take a little to propagate to Quicklisp) by adding the proper nickname to the package, i.e., "CL-UNIFICATION". My excuse is that this was a left over from a few years back when nomenclature had not been as settled. :)

Printing XHTMΛ

2011-06-14T02:05:00.000-07:00

I finally bit the bullet! I swear I tried! I pestered people! I failed. I.e., I failed to like any of the "major" HTML-producing libraries "out there" and so I rolled up my own. In the process, I (re)learned a few things and I believe I made good use of parts of the language that are usually overlooked.

My problems with the other libraries

This section must start with an apology.

All the libraries I tried, are very fine and sophisticated pieces of software that do solve problems. Alas, myself being a rotten Lisper, I found that I "needed something different" (read: "something I wrote"). Therefore, the comments you'll read below are not to be intended as general statements about such libraries, but only as testimony of my whims.

The libraires I looked at are CL-HTTP, CL-WHO and variations of TFEB's htout and Franz htmlgen, especially in the XHTML-GENERATOR version that comes with CXML.

As I said, my idiosyncrasies with the the whole business of CL programming found problems with each of these otherwise fine libraries. More specifically, I found CL-HTTP too heavy to use just to generate HTML. One gripe I had with CL-WHO is that it did not handle pretty printing of HTML well (indentation is off in "recursive" use); more or less the same can be said of htout and htmlgen. CXML XHTML-GENERATOR is essentially a "round-trip" utilities and it makes your life quite unhappy if you are trying to use simple HTML entities like - surprise - λ and Λ.

CL-WHO, htout, htmlgen and XHTML-GENERATOR all take the approach summarized as I will compile a SExp representing "HTML" and will generate - in line - a set of specialized writing calls (yes: mostly WRITE and WRITE-STRING). (Cfr. the examples in CL-WHO documentation; .)

There is nothing wrong with this approach, but it makes the resulting library and overall implementation more monolithic and it does not leverage some of the bells and whistles that you have available in CL. Thus I rolled my own (and I called it XHTMΛ).

Yet anotherⁿ HTML generation library

My approach to HTML (or XML) generation is the following:

HTML (or XML!) element need not be "lists" or "conses"; they can be bona-fide objects, i.e., structures.
print-object, and, above all, the pretty printer are my friends.
*print-pretty*, *print-readably* etc., are more than useful.

There are a few consequences from this choices and they should be exposed. Before doing that, let's see what happens in the basic case.

The basic definition in the implementation of XHTMΛ is the representation of a HTML (or XML!) "element". It is very simple and it does accommodate the HTML5 bits and pieces.


(defstruct (element (:constructor %element))
   (tag        nil :type symbol)
   (attributes ()  :type list)
   (content    ()  :type list))

tag is ... the tag, attributes is a p-list and content is a possibly empty list of other elements.

"Printing" an element

Let's forget a minute about the constructor and let's instead concentrate on an element "printing" process. The main entry point is a print-object method.


(defmethod print-object ((e element) (s stream))
  (let ((tag (element-tag e))
        (attributes (element-attributes e))
        (content (element-content e))
        )
    (cond (*print-pretty*
           (pprint-xhtml s e))

          (*print-readably*
           (format s "#S(~S :TAG ~S :ATTRIBUTES ~S :CONTENT ~S)"
                   (type-of e)
                   tag
                   attributes
                   content))

          (t
           ;; Format string showing-off!!!!
           (format s "<~A~{ ~A=\"~A\"~}~:[ />~;>~:*~{~S~^ ~}</~3:*~A>~]"
                   (string-downcase tag)
                   attributes
                   content
                   )
           ))
    ))

The method is rather straightforward (apart from the last format string, which does many things at once: (1) writes the attributes, (2) checks whether there is content and if not closes the tag, otherwise backs up to print it, and (3) finally it backs up again to the tag to print the proper closing element). Note that, in order to properly and nicely printing the element, if *print-pretty* is non-NIL, then the function pprint-xhtml is called.

Using the pretty printer

It may be just me, but I believe that the pretty printer is an under-used part of the CL standard. Therefore, I set out to use it heavily in order to get "properly indented" (meaning, the way I like it) (X)HTML. The function pprint-xhtml does that.


(defun pprint-xhtml (s xhtml-element)
  (declare (type stream s)
           (type element xhtml-element))
  (let ((tag (string-downcase (element-tag xhtml-element)))
        (attrs (element-attributes xhtml-element))
        (content (element-content xhtml-element))
        )
    (pprint-logical-block (s content)  ; (1)
      (pprint-logical-block (s content)  ; (2)
        (format s "<~A~@<~{~^ ~A=\"~S\"~^~_~}~:>" tag attrs)  ; (3)
      
        (when content
          (write-char #\> s)
          (pprint-newline :mandatory s)
          (format s "~{~4,0:T ~:W~_~}" content)
          ))

      (if content
          (format s "~0I</~A>" tag)
          (format s " />"))
      )))

The function requires a few explanations (of course, if you are a "pretty printer black-belt" this may be a bit boring). First of all, a display of what I want to obtain.

<body style="color: red">
    <p>
        Some text here
        <ul>
            <li>
                Line 1
            </li>
        </ul>
    </p>
</body>

This indentation may not be the best possible and there are some pitfalls, but it is better than what you get with the other libraries. But how does the function pprint-xhtml achieve this result while interacting with the pretty printing machinery?

The function pprint-xhtml uses three logical blocks. Two for the element and a third for the attributes. The logical block for the attributes is introduced in the format string using the ~@< ... ~:> directive. Note also the conditional newline ~_ in the list iteration construction ~{ ... ~}. The other two pprint-logical-block establish the fence for the whole element and for the "inside" of the same. The outer pprint-logical block serves essentially to print the closing tag (if needed) correctly indented. The "inner" pprint-logical-block just serves to provide the correct indentation for the tag and the actual element content. The pprint-newline and the indentation directive in the format string, do the rest.

Once you wrap your head around it (it did take me some time!) it is very straightforward, and very powerful.

Bells and Whistles

The pretty printing machinery offers you more control over what you can do with it. For the time being my code just uses one simple hook into the pretty printer dispatch table in order to write strings "unquoted", but, potentially, this is the machine to provide fancier element layout.

The actual "printing" of an element is controlled by a specialized macro (provisionally) called with-html-syntax which calls write with an appropriately setup :pprint-dispatch argument.

The variable *xhtml-pd* holds the modified pretty print dispatch table, which it is initialized as follows (at a minimum):


(set-pprint-dispatch 'element
                     'pprint-xhtml
                     0
                     *xhtml-pd*)

(set-pprint-dispatch 'string
                     (lambda (s xhtml-string)
                        (write-string xhtml-string s))
                     0
                     *xhtml-pd*)

This is the result:


XHTMLAMBDA 29 > (with-html-syntax (*standard-output* :print-pretty t)
                  (body (:style "color: red")
                        (p ()
                           "Some text here"
                           (ul ()
                               (li () "Line 1")))))
<body style="color: red">
    <p>
        Some text here
        <ul>
            <li>
                Line 1
            </li>
        </ul>
    </p>
</body>
<body style="color: red"><p>"Some text here" <ul><li>"Line 1"</li></ul></p></body>  ; This is value returned!

XHTMLAMBDA 30 >

XHTMΛ Syntax

As you have noted in the previous example, the syntax of a XHTMΛ elements is


   (tag attributes . content)

where each tag is implemented as a macro, which is essentially in charge of delaying the evaluation of the content plus some other massaging, mostly flattening of the content lists, this is achieved by having each macro calling a first parsing step, which generates an "intermediate" form that eventually calls the element function (see below). The following example shows a pretty standard trick:


XHTMLAMBDA 33 > (with-html-syntax (*standard-output* :print-pretty t)
                  (body (:style "color: red")
                        (p ()
                           "Some text here"
                           (ul () (loop for i below 5
                                        collect (li () (format nil "Line ~D" i)))))))
<body style="color: red">
    <p>
        Some text here
        <ul>
             <li>
                 Line 0
             </li>
             <li>
                 Line 1
             </li>
             <li>
                 Line 2
             </li>
             <li>
                 Line 3
             </li>
             <li>
                 Line 4
             </li>
        </ul>
    </p>
</body>
<body style="color: red"><p>"Some text here" <ul><li>"Line 0"</li> <li>"Line 1"</li> <li>"Line 2"</li> <li>"Line 3"</li> <li>"Line 4"</li></ul></p></body>

XHTMLAMBDA 34 >

Thus XHTMΛ is unlike most other libraries which just discriminate on the first element of a SExp, usually a keyword. XHTMΛ wants more structure and it strives to be more easily extensible through "standard" and low-level machinery, cfr., the pretty printing machinery and CLOS. As an aside, the %element constructor is there just to be called by a "factory" generic function called - you guessed it - element.

Other Syntaxes and the `HTMLIZE` Macro

Yet there is value in the widely used alternative SExp syntax for HTML (and XML):


  (tag . content)


  ((tag . attributes) . content)

In order to accommodate such syntax (and also a "keyword-based" one), XHTMΛ provides a htmlize macro which does some more rewriting from the syntax just above (termed :compact) to the "operator-and-attributes" syntax (termed :standard).


XHTMLAMBDA 39 > (htmlize
                 ((body :style "color: red")
                  (p "Some text here"
                     (ul (loop for i below 5
                                  collect (li () (format nil "Line ~D" i))))))
                 )
<body style="color: red"><p>"Some text here" <ul><li>"Line 0"</li> <li>"Line 1"</li> <li>"Line 2"</li> <li>"Line 3"</li> <li>"Line 4"</li></ul></p></body>

Availability

The XHTMΛ library will be available "very soon"™ in common-lisp.net. Stay tuned!

References

[W93] Richard C. Waters, Some Useful Lisp Algorithms: Part 2, Mitsubishi Electric Research Laboratories Technical Report 93-17, August, 1993.

[S90] Guy L. Steele Jr., Common Lisp, the Language, 2^nd Edition, Digital Press, 1990.

NEW code and documentation for the NEW op library.

2011-03-10T05:37:00.000-08:00

I added code and updated the documentation for the NEW-OP library to handle STRUCTURE-CLASS better. Cfr., NEW-OP on common-lisp.net.

(cheers)

:constructor tricks

2011-02-25T01:31:00.000-08:00

Every once in a while I discover things in CL that somehow I had not thought about before. They have been there sometimes since CLtL1 but, somehow, I did not register them before. (I am slow, I know; and I am not claiming that this is anything new. But this is the Internet :) )

Fancy :constructor uses are one of these things.

Suppose you wanted to construct a immutable tree node structure which recorded the height of the sub-tree upon construction. Here is an iteration of what you may do.

(defstruct node
   (height 0)
   left
   right)

Now you need to create the constructor for nodes. Not worrying about nil nodes, you may start by doing the obvious (assuming a max* function capable of dealing with nil values):

(defun build-node (l r)
   (make-node :left l
              :right r
              :height (1+ (max* (node-height l) (node-height r)))))

Ok. Fine. But why having two constructors, with the standard make-node essentially useless (you would not want to advertise it, as height is a computed slot)?

However, you can do the following:

(defstruct (node
           (:constructor make-node (left right
                                    &aux
                                    (height (1+ (max* (node-height left) (node-height right))))))
   (height 0)
   left
   right)

This will work as expected; the key trick is to leverage the &aux parameter to collect the computation. Adding the appropriate :read-only declarations, you end up with:

(defstruct (node
           (:constructor make-node (left right
                                    &aux
                                    (height (1+ (max* (node-height left) (node-height right))))))
   (height  0 :read-only t :type (mod 42))
   (left  nil :read-only t :type (or null node))
   (right nil :read-only t :type (or null node))

A perfectly fine immutable node structure.

(cheers)

NEW structure and class constructor handling?

2011-02-24T08:02:00.000-08:00

In a previous post I mused about having a new new operator for Common Lisp.

The only rub in the scheme I came up with was the handling of DEFSTRUCT constructors, which had to be somehow recorded in the system in order to make them known to the new operator.

The solution was less than satisfactory, and I had been thinking about how to come up with something more pleasant. Now I believe I found something acceptable by relaxing the basic new invariant (cfr., the spec) and admitting two "pseudo" types as arguments. Suppose we had a "pseudo" type (class class-name) and a "pseudo" type (struct structure-class-name). Now I could write:

cl-prompt> (defclass foo () ())
#<STANDARD CLASS FOO>

cl-prompt> (newq (class foo))
#<FOO @ 42>

The twist is that now I have the right structure to plug in the constructor for structures.

cl-prompt> (defstruct baz q w e)
BAZ

cl-prompt> (newq (struct baz) :q 42)
#S(BAZ :Q 42 :W NIL :E NIL) ; The standard MAKE-BAZ constructor is called.

cl-prompt> (defstruct (bar (:constructor barify (a s &optional d)
                           (:constructor new-bar))
               a s d)
BAR

cl-prompt> (newq (struct bar :by barify) 1 2)
#S(BAR :A 1 :S 2 :D NIL)

cl-prompt> (newq (struct bar :by new-bar) :s 2 :a 1)
#S(BAR :A 1 :S 2 :D NIL)

I think this does it and it is not so bad. Any comments?

(cheers)

EQUALITY and COMPARISON to CDR

2011-02-16T02:20:00.000-08:00

I submitted the proposal for equality and comparison (cfr. my previous post) to the CDR discussion fora.

(cheers)

All things being equal...

2011-01-30T09:21:00.000-08:00

Alright, this has been floating around for some time and it is time to write it up.

Several object-oriented languages (e.g., Java, Ruby, C++, etc.) have ways to define equality and comparison operators or methods. In Java the Object class defines the equals method, which can be specialized in user code and the Comparable<T> interface.

In Common Lisp, while all the machinery is there to provide such facilities, there has been no push to provide them. I think there are two reasons for this. The first one lies in the widespread use of :test keywords and the programming style it encourages, especially when writing libraries. The second in the influential KMP's paper on The Best of Intentions: EQUAL Rights - and Wrongs - in Lisp.

The first reason does not really needs discussing, the second, a bit. In my honest opinion, there are no real reasons not to have a notion of generic equality (and comparisons) on top of the standard :test machinery, provided that some caution is taken.

Having said so, I built methods for the following generic functions.

(defgeneric AEQUALIS (a b &rest keys &key recursive-p &allow-other-keys)
 (:method ((a T) (b T) &rest keys &key recursive-p &allow-other-keys)
    (eq a b))
 )

(defgeneric COMPARE (a b &rest keys &key recursive-p &allow-other-keys)
   ...)

AEQUALIS is Latin for "equal". The generic function COMPARE returns <, >, =, or /=.

I prepared a specification for them (and an implementation) in order to post a CDR. You can find it in the CLEQCMP directory on my Google docs.

Comments welcome.

Enjoy

(cheers)

NEW project on common-lisp.net

2011-01-07T07:13:00.000-08:00

There is a NEW project on common-lisp.net. The new-op pages contain documentation and download instructions to get the code for the new operator in Common Lisp I described in a previous post.

(cheers)

CLAZY and ENUMERATIONS

2010-12-19T05:25:00.000-08:00

I submitted CLAZY and CL-ENUMERATIONS to Quicklisp and found out that there were some problems with them. Mostly due to (unwarranted) package locks in SBCL and CLISP. Fixing these problems led to some revisitation of the code base and subsequent improvements (I hope).

Both libraries should appear in future Quicklisp releases.

(cheers)

HTML in Common Lisp: code or fill?

2010-12-06T07:05:00.000-08:00

I finally got around to write my very own HTML documentation system. Of course, this may be pointless and useless, but I found the alternatives "out there" lacking this or that (obviously!). So here I am, trying to automate the process of producing documentation like that of CLAZY, which I hand-crafted in the past. In the process, needless to say, I got carried away and got lost in the land of featurism only to contemplate my overall ignorance of most things webbish.

As usual, Edi Weitz came to my rescue by offering his CL-WHO and HTML-TEMPLATE, which raised a question: which of the two approaches is best? Note that the answer should consider how many dependencies my system files can have.

Let's start with the simple problem I have: I need to produce a .html file that contains, say, a "header" for my documentation. I could do it using CL-WHO in the following way (just a snippet, not working...)

(defun produce-header-file (fs header-pathname)
(declare (type frameset fs)
      (type pathname header-pathname))
(let ((fs-order (frameset-order fs))
   (fs-head-title (frameset-head-title fs))
   (fs-body-title (frameset-body-title fs))
   )
(with-open-file (hs header-pathname
                   :direction :output
                   :if-exists :supersede
                   :if-does-not-exist :create)
 (with-html-output (hs hs :indent t)
   (fmt "~A" (cl-fad:pathname-as-file header-pathname))
   (fmt +doctype-frameset-control-string+)
   (:html
    (:head
     (:title (str fs-head-title))
     (:link :rel "stylesheet" :href "clstyle.css"))
    (:body :style "margin: 0pt 0pt 0pt 0pt;"
     (:div
      :class "header"
      :style "padding-left: 2em; padding-top: 5pt; color: #41286f; font-size: 14pt"
      (:strong (str fs-body-title))
      (:div
       :class "navigation"
       :style "right: 2m"
       (:a
        :href "index.html"
        :class "navigation-link-selected"
        :target "_parent"
        (str "Home"))
       )))))
 )))

Or I could use HTML-TEMPLATE and ship around a "template" file like the following (again, this is just a snippet and contains errors):

<!-- header.html -->

<!DOCTYPE HTML PUBLIC
"-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html>
<head>
<title><!-- TMPL_VAR HEAD_TITLE --></title>
<link rel="stylesheet" href="clstyle.css">
</head>

<body style="margin: 0pt 0pt 0pt 0pt;">

<div class="header"
style="padding-left: 2em; padding-top: 5pt;  ">
<strong><i><!-- TMPL_VAR BODY_TITLE --></i></strong><br/>

<div class="navigation" style="right: 2m">
<!-- TMPL_LOOP frames -->
<!-- TMPL_IF current_frame -->
<a href=<!-- TMPL_VAR frame --> class="navigation-link-selected" target=_parent><!-- TMPL_VAR f_nav_name ->></a>
<!-- TMPL_ELSE -->
<a href=<!-- TMPL_VAR frame --> class="navigation-link" target=_parent><!-- TMPL_VAR f_nav_name ->></a>
<!-- /TMPL_IF -->
<!-- /TMPL_LOOP -->
</div>

</div>

</body>
</html>

<!-- end of file : header.html -->

I am inclined to go the CL-WHO way. I do not have to ship around an extra file and record its location etc etc; yet the HTML-TEMPLATE does have appeal. Any ideas out there?

(cheers)

NEW post

2010-10-05T08:04:00.000-07:00

Hello,

here is a NEW post after a long time. And the topic of this post is NEW. Of course, this is old stuff, but here it is: it's a post about the new operator. I'd bet there are many other little hacks like this floating around, but I finally got sucked in into writing a little library that introduces a new operator (and a newq one) in Common Lisp.

Why? After a very long time of putting up with make-instance and make-this and make-that, and after many other brain things going on in my head (cit. King Julien of the Lemurs) I decided that Common Lisp needed something capable of doing the following:

cl-prompt> (defclass foo () ())

FOO

cl-prompt> (new 'foo)

#<FOO instance 42>

or even

cl-prompt> (newq foo)

#<FOO instance 42>

So; what's the big deal? Not much, but I also want to be able to write:

cl-prompt> (newq (array single-float (2 2)) '((1.0 0.0) (0.0 1.0)))

#2A((1.0 0.0) (0.0 1.0))

The problem is that as soon as you wade in CL "type specifiers" land, you hit the dreaded "implementation dependent" wall, or, worse, the "this is not even mentioned in the ANSI spec" wall. Think of DEFSTRUCT and the fact that there is no portable way to get to the constructor, not to mention DEFTYPE.

Apart from that, I think that the little piece of code I wrote would maybe make programming in CL feel more in tune with the times. After all you can also write things like the following, which I think are rather cool.

cl-prompt> (new '(mod 42) (read))

1024

Error: 1024 is not of type (INTEGER 0 (42)).

...

What do you think? Is this worth a CDR? Ping me if you want to see the code.

(cheers)

ELS 2009 tomorrow

2009-05-26T00:29:00.000-07:00

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)

2009-04-15T03:30:00.000-07:00

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.

2009-03-27T06:29:00.000-07:00

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....

2009-02-26T05:43:00.000-08:00

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....

2009-02-19T07:56:00.000-08:00

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

2009-02-17T02:17:00.000-08:00

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...

2009-02-17T00:59:00.000-08:00

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....

2009-02-16T08:33:00.000-08:00

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

(within parens...)

European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012

Important dates:

Program Commitee:

Mokum ECML 2011

CL-UNIFICATION system and package names aligned.

Printing XHTMΛ

My problems with the other libraries

Yet anothern HTML generation library

"Printing" an element

Using the pretty printer

Bells and Whistles

XHTMΛ Syntax

Other Syntaxes and the HTMLIZE Macro

Availability

References

NEW code and documentation for the NEW op library.

:constructor tricks

NEW structure and class constructor handling?

EQUALITY and COMPARISON to CDR

All things being equal...

NEW project on common-lisp.net

CLAZY and ENUMERATIONS

HTML in Common Lisp: code or fill?

NEW post

ELS 2009 tomorrow

CL-UNIFICATION does regexps (thanks to Edi Weitz)

Maybe a bug? Some considerations.

Lazily cleaning up....

Feeling lazy....

European Lisp Symposium 2009 in Milan, Italy

Naming packages...

Here I am....

Yet anotherⁿ HTML generation library

Other Syntaxes and the `HTMLIZE` Macro