20111117

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

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

20111023

Mokum ECML 2011

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)

20110616

CL-UNIFICATION system and package names aligned.

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

20110614

Printing XHTMΛ

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 anothern HTML generation library

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

  1. HTML (or XML!) element need not be "lists" or "conses"; they can be bona-fide objects, i.e., structures.
  2. print-object, and, above all, the pretty printer are my friends.
  3. *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)

or


  ((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, 2nd Edition, Digital Press, 1990.

20110310

NEW code and documentation for the NEW op library.

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)

20110225

:constructor tricks

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)

20110224

NEW structure and class constructor handling?

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)

20110216

EQUALITY and COMPARISON to CDR

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

20110130

All things being equal...

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)

20110107

NEW project on common-lisp.net

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)