skip to main |
skip to sidebar
- When you update to HEAD make sure you enable the slime-repl contrib, otherwise you'll be stuck to an old-school inferior-lisp REPL, only.
Recommended: Use the slime-fancy meta contrib which enables various useful features you'll probably enjoy.
- C-u C-c C-c will compile the defun at point with maximum debug optimization setting. (SBCL only so far.)
- Bleeding edge feature: M-- C-c C-c will compile the defun at point with maximum speed optimization setting (still SBCL only.) This is very useful to benefit from SBCL's type inference and elicit compiler notes.
Just a moment ago, I was able to dig out a definitive answer for an old question of mine: Can one expect macros to be expanded in the order they textually appear in a source file?Answer: No, you cannot.The expectation originated in Common Lisp's evaluation model (CLHS 3.1.2) which can be described to be basically top-down, left-to-right (CLHS 3.1.2.1.2.3).That expectation was short-sighted, though, as processing and evaluating are two differen things. And, indeed, item #6 in CLHS 3.2.3.1 specifies:Note that top level forms are processed in the order in which they textually appear in the file and that each top level form read by the compiler is processed before the next is read. However, the order of processing (including macro expansion) of subforms that are not top level forms and the order of further compilation is unspecified as long as Common Lisp semantics are preserved.
Which makes perfect sense as it allows compilers to do transformations on the Lisp source code before or along macroexpansion.
For example, UNWIND-PROTECT could be a macro turning
(unwind-protect (protected-form)
(cleanup-form1)
(cleanup-form2))
into
(let ((cleanup-thunk #'(lambda () (cleanup-form1) (cleanup-form2))))
(declare (dynamic-extent cleanup-thunk))
(%establish-unwind-guard cleanup-thunk)
(protected-form)
(funcall cleanup-thunk) ; no unwinding happened
(%remove-unwind-guard))
The purpose of my blog is to share the knowledge I have acquired over the last 4 years I've been learning Common Lisp. Even after (almost) 4 years, I wouldn't dare to assert to know the language in its entirety; there are still major areas I'm only superficially familiar with.My rationale behind this endeavor is two-fold.- On one hand, I want to offer a ressource for people that already have experience with Common Lisp to gain even more thorough understanding of the language---so they can ascent to the next level so to speak.
- On the other hand, I want to preserve information for myself. The human mind is generally not capable of keeping too many details for a long period of time around. Hence, I'd like to use this blog as a swapping device for stuff I once spent time on.
I'll start with a series about writing macros correctly---correctly as in consistently to how the macros in the Common Lisp standard behave. There are lot more issues involved in writing correct macros than the widely known problems of unwanted variable capture, and multiple evaluation.I'm looking forward to comments about the upcomming postings, and to suggestions for things to write about. You can always reach me via e-mail (trittweiler, common-lisp, net.) -T.
Last Wednesday, I gave a talk to the Munich Lisp Group about SLIME, the Superior Lisp Interaction Mode for Emacs. An perfect opportunity for opening my blog!
The presentation can be found at
It was an honor to see that so many people (about 25), partly from very far abroad!, showed up to see myself talk about the stuff I hacked over the past two years. The age distribution was also very diverse, from early twenties to mid forties, I guess. I was especially pleased to notice that the average age drifted more towards the younger end than to the older one.
The background of all the people was also very diverse, and very fascinating. As the resonance of the talk has been very positive (thanks all!), it was decided to regularly uphold such meetings in the future. If you're close to Munich, go, and subscribe to the mailinglist!
