On Common Lisp "style"
Whenever I see code written by other people - especially Common Lisp code - it makes me realize that I am quite obsessed about writing my own code in a very particular style. This style consists of lexical rules (ones dealing with how the code looks) and idioms (certain CL constructs are to be used in lieu of others in certain situations). Long time ago, when working at CMU, I actually wrote a guideline and distributed it to the other folks working in the same project - they thought I was pretty much insane. Oh well...
I will discuss the lexical rules first: Common Lisp is always written in lower case. Names with multiple parts are written with parts separated with hyphens (e.g.,
foo-bar). "Camel case" (e.g.,
FooBar) is not permitted. Names of predicates (i.e., functions yielding a boolean value) end in a "p". If a predicate has a multi-part name, then the "p" is separated with a hyphen. Some standard functions of Common Lisp represent exceptions to this rule (e.g.,
atom), mostly for historical reasons. Global variables (i.e., those introduced with
defparameter) are named using asterisks at both ends. Global constants (i.e., those introduced with
defconstant are named with hyphens at both ends. Macros that assign values to generalized variables have names that end in an "f".
Common Lisp programs are always written with a Decent Editor (such as gnu-emacs). Any Decent Editor knows how to indent Common Lisp programs. It is futile to try to defeat the editor's indentation rules and/or to indent by hand.
Comments are introduced using the semicolon character. The number of consecutive semicolons determines the (automatic) placement of the comment:
A single semicolon introduces a comment placed at the end of a line containing code.
Two semicolons introduce a comment indented at the indentation level of the code.
Three semicolons introduce a comment placed at the beginning of a line.
Four semicolons introduce a comment indicating the title of a file or a bigger code block.
Since a Decent Editor will observe these conventions and indent accordingly, it is again futile to try to defeat the indentation rules. For an in-depth discussion about commenting conventions, see CLtL2 pp.526-527.
At some later date, I will discuss the idioms.
Wilbur mentioned in a C|Net article!
Recent article on C|Net about the Semantic Technology Conference had a reference to Wilbur. Cool.
Wilbur manual - finally?
I have finally started writing a proper manual for Wilbur. Sure, there has been a brief description of the APIs, but it has not really been updated since the first release (and it wasn't really up to date even then). I was thinking of something that combines a reference manual and a "cookbook".
I have always liked the look and style of CLtL2, and I would like to mimic that to the extent possible. I found the LaTeX sources of CLtL2, but these were produced for some old version of LaTeX (so old, in fact, that even when LaTeX2e reverts to the "compatibility mode" the files still won't compile). I don't grok TeX enough to be able to figure out (with reasonably small effort) how to fix some of the macros, so I wrote my own (those of you who think it is hard to read someone else's Perl code, try reading TeX style definitions...).
Anyway, with my new "defun", "defmethod" etc. LaTeX environment definitions, I am underway. Now I just need a little Common Lisp program to take the function, method etc. signatures and turn them into a skeletal draft of the reference manual...
Everyone seems to have a blog these days. I wanted one too. I would like to discuss the Semantic Web and Common Lisp, and their intersection, the Wilbur toolkit.
Posted by ora at 11:49