an immense accumulation of commodities

Christophe Rhodes had tipped me to this, which some have not seen. The interesting part is in the fifth paragraph: “Unsurprisingly, the reaction has been mixed with some applauding how Arc strips the Lisp language down to its bare essentials.” Note who the applause comes from.

Last night was the first ZSLUG (Zürich Scheme/Lisp Users Group) meeting at the Lion Bar. This turned out to be both a fantastic success - in that about 15 people turned up - and something of a failure - in that there were so many people it became impractical for Juho to complete his presentation on SBCL code coverage. The search for an alternative venue/plex is on…

Down my end of the table(s) talk was about R6RS and the social psychology of standardisation; ARC and the rôle of Paul Graham in the (Common) Lisp community; theoretical physics and the bandwidth requirements of CERN; performance characteristics of Bigloo, SBCL and Chez Scheme; why developing in Schemes other than Scheme48 is painful and the wonders of Slime; and the mystery of where all the lispers maintaining the Swiss International Airlines Limited application have gone.

I made a particularly unconvincing argument for the wonders of CLIM and Climacs. Must do better!

I was the first to leave, so things might well have broken up acrimoniously by the end of the evening, but judging on what I saw and heard I would have to say that ZSLUG has a great future ahead of it.

In my last post I asked whether anyone knew how to replace automatically numbered paragraphs in MS Word with their textual (non-auto) equivalents.

No one replied.

So I had to do it myself. Startlingly simple for my humble needs, the solution consists of a key-code invoking a macro which shells out to cscript running a Jscript program. The slightly interesting point is that this last is generated by Parenscript, and looks like so:

(defvar wd-app (*get-object "" "Word.Application"))
(defvar a-doc wd-app.*active-document)

(defun de-number ()
  (let ((cnt a-doc.*lists.*count))
    (dotimes (i cnt)
      (let ((lst (slot-value (a-doc.*lists 1)
                             '*range.*list-format)))
        (lst.*convert-numbers-to-text 3)))))

This is obviously far from being great style, but it gets the job done and has me wondering about all the other things I could be doing with parentheses…

In “To NReverse When Consing a List or By Pointer Manipulation, To Avoid It; That Is the Question” (in Some Useful Lisp Algorithms: Part 2, MERL TR93-17, August, 1993), Richard C. Waters discusses whether it’s better, when consing up “a list of elements where the order of the elements in the list is the same as the order that they are created in time”, to push and nreverse or “maintain a pointer to the end of the list and use rplacd to put each element directly into its proper place in the list.” Waters’ conclusion is that nreverse is (was) often faster, but that in any case the speed difference is not enough to avoid the simpler nreverse approach.

To examine the differences Waters used two simple functions, maplist-nreverse:

(defun maplist-nreverse (f list)
  (do ((sub list (cdr sub))
       (r nil (cons (funcall f sub) r)))
      ((null sub) (nreverse r))))

and maplist-rplacd:

(defun maplist-rplacd (f list)
  (let ((r (cons nil nil)))
    (do ((sub list (cdr sub))
	 (end r (let ((x (cons (funcall f sub) nil)))
		  (rplacd end x)
		  x)))
	((null sub) (cdr r)))))

Timing the functions using #'identity as the map function he got the following results (Lucid Common Lisp on an HP-730):

(where the numbers represent computation time in microseconds per cons created).

For no real reason I replicated this on an Intel Core2 T7200 2.0GHz running Win32 and sbcl 1.0.6:

(where the numbers represent computation time in microseconds per element of the input list).

Although the trend seems to be for the rplacd version to be slightly faster, the differences seem minor, and we might as well adopt Waters’ recommendations:

In closing I would like to note that the very best thing to do is to avoid writing code that conses lists altogether. Whenever possible, you should use standard parts of Common Lisp that do the consing for you. In particular, you should use functions like replace, map, reduce, remove, union, etc. whenever they are appropriate. Beyond this, you should take advantage of looping macro packages such as loop and Series.

A1

Your favourite lisp(s) + emacs + Slime (+ paredit) constitute a fabulous development environment that is widely used, and therefore widely supported, on #lisp. Eschewing this environment for something else will make it far harder for people to understand your problems and (if you ask nicely, and intelligently) help you with them.

(I also find it telling that when the smart folks who started developing lisp had the time and energy to build editors they built emacsen.)

However, if you really can’t stand emacs (perhaps because of a childhood incident with Richard Stallman, a wasp’s nest and a jar of manuka honey), you could use plain Vi (and give up the wonders of Swank) or Cusp, if you’re an Eclipse fan.

But don’t come running to us when something goes wrong.

A2

“I want to learn Russian but I can’t be bothered with all the funny characters.”

* “FEP” = Frequently Expressed Predjudice

A1

By following the instructions for your lisp implementation:

• sbcl - (sb-ext:save-lisp-and-die filename :executable t)
• clisp - (ext:saveinitmem filename :save-executable t)
• OpenMCL - (require "COCOA-APPLICATION")
• ECL - (c:build-program ...)
• Allegro - (generate-executable ...)
• LispWorks - (deliver ...)

These last two have a whole host of bells and whistles (including, in the case of LispWorks, a tree-shaker), but require the paid-for versions. (You should also check their royalty requirements.)

A2

Why would you want to? Really? What commonly distributed systems in this day and age come in a single executable file, except as a delivery mechanism that subsequently sprays various libraries, databases and settings mechanisms around your filesystem?

Newcomers to Common Lisp are encouraged to use Emacs (see also Finseth) so that they can use the fabulous Slime (and one should not forget paredit) as a development environment. Those that don’t insist they’ll stick with Vim (and then unaccountably fail to develop slim-vim), or try Cusp, will at some early point be advised to swap their Control and Caps Lock keys to save wear and tear on the pinkie. Even EmacsWiki points to typically forthright Steve Yegge piece which leads off with this advice.

I say - No. The proper place for the Control key is not “on the home row” but on each side of the Space Bar, where Tom
Knight and the mothership intended them to be. And outside the Control keys should be the Meta keys, and outside them should be the Super keys, and finally the Hyper keys. This allows for what I think is a very natural way of typing key-chords - the modifiers with one hand, and the letter/symbol with the other. These are, after all, the sorts of keyboards on which Emacs was first developed.

How you do this will depend on your OS and your keyboard. For Windows, you might like to start here or here.^* In OSX you can look in System Preferences > Keyboard & Mouse > Modifier Keys. For Linux, there are a thousand xmodmap and xkb tutorials…

The other keyboard reconfiguration I recommend is, where possible, to put the parentheses on unshifted keys (swapping with the [square] brackets works on some keyboards). Of course, if, like me, you live/work in a locale with all manner of chicken scratchings on top of proper latin letters this may not be possible or convenient. (Eric Naggum’s more radical approach can be seen here.)

So, my advice for Emacs (Climacs, VBacs) newbies would be: don’t swap Caps-Lock and Control, swap Alt, Ctrl, Windows, Application, AltGr…

1. Fire up regedt32.exe and navigate to HKEY_CURRENT_USER\Keyboard Layout.
2. Create a new entry Scancode Map (using Edit > New > Binary Value).
3. Edit the new entry (using Edit > Modify Binary Data) to contain the following:

       0000   00 00 00 00 00 00 00 00
       0008   04 00 00 00 1D 00 38 00
       0010   38 00 5B E0 5B E0 1D 00
       0018   00 00 00 00

   The table is in little-endian form. The first 8 bytes are header (all zeroes). The next four bytes contain the count of entries (4, including the sentinel). The three following four byte entries swap Left Alt (0x38) with Left Ctrl 0x1D), Left Win (0xE058) with Left Alt, and Left Ctrl with Left Win. The last 4 bytes are a null terminator/sentinel.

4. Close up, log off, log on, and enjoy.

If you did this, of course, it would be entirely at your own risk.

Hot on the heels of the rudiments of a C syntax for Climacs, I’m about to commit a Java(TM) syntax. This one is slightly better, and should lead to improvements in the C syntax, too. (And, eventually, some refactoring of the - many - common elements.) Like the C syntax, this one does not yet try to parse too much Java grammar, but in the absence of a preprocessing stage, I have less excuse. On the other hand, the progressive layering of things like annotations (which look to this non-Java person like an afternoon’s work with a thin macro layer over symbol plists) and generics make the Java grammar distinctly grody. It’s a pity about infix, too…

“Java” is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. They have an awful lot.

As a diversion from all the things I promised myself I’d be doing after ilc07, I’ve ended up playing with a C language syntax (mode) for Climacs.

When previewing on #lisp, the first question everyone had was “how accurately does this parse C?” Well, the answer is: at the moment, not at all. And I thought that, in the presence of C’s textual preprocessing facility*, that’s the way it would have to be. But looking briefly at emacs’ cc-mode, it looks like it ends up doing the closest thing to a full parse anyway, so I have some way to go…

More seriously, the C syntax uses the same LR parsing infrastructure that the existing Lisp syntax uses, so I’ve begun to abstract that out into its own LR-parsing mixin syntax. (I love mixins.) But it’s early days yet.

(This posted to shame me into actually delivering a patch to McClim reasonably soon rather than waiting for things to bit-rot. Which is the other thing — the wonder that is Drei means that this syntax is available to all text gadgets in McClim. Think of the possibilities…)

* “Many other changes occurred around 1972-3, but the most important was the introduction of the preprocessor. … Its original version was exceedingly simple, and provided only included files and simple string replacements: #include and #define of parameterless macros. Soon thereafter, it was extended … to incorporate macros with arguments and conditional compilation. The preprocessor was originally considered an optional adjunct to the language itself. … This attitude persisted, and explains both the incomplete integration of the syntax of the preprocessor with the rest of the language and the imprecision of its description in early reference manuals.” Ritchie, The Development of the C Language, 1993, in History of Programming Languages-II ed. Thomas J. Bergin, Jr. and Richard G. Gibson, Jr. ACM Press (New York) and Addison-Wesley (Reading, Mass), 1996

Well, ilc07 was pretty fabulous. The setting and the weather was unfeasibly beautiful. (I found/find it interesting that a not insignificant number of people were compelled to invoke Harry Potter in response.) The organisation was great, and the papers and presentations of a pretty consistently high standard. My notes follow. They will make most sense to those who were there, I guess.

Day 1

MPS: Disappointingly too much reminiscing about dead projects. I didn’t mind the business anecdotes (although the frogs were unnecessary). The MPS system itself seems very interesting, but I felt we got only the merest glimpse.

Debugging: OK. Interesting that there seems little difference between a commercial lisp and something like SBCL. ll (low-level language, as opposed to LAP) seems an ideal target to which to compile C…

Day 2

Lisp: Themes and History: A presentation in two parts. The first a fascinating piece of lisp archeology. (LISP looked real ugly pre-parens.) The second a quick overview of semantically-preserving rewrite rules to compile lisp to a machine independent LAP. But why?

Constraint Propagation: Probably very good, but I didn’t understand why I should care. As Christophe Rhodes has already mentioned, a number of the talks lacked the slide on the motivation for the research/approach/product/technique.

Binary DSL in Dylan: Engaging presenters. Two takeaways: there is life in Dylan yet, and procedural macros rule.

FREEDIUS: Looked cool, but what is it for? (I wonder if it can track a ball in real time?)

ESA: I enjoyed it (: Very useful for when you need that instant gui gratification.

Ltk: Like ECLM’06 but with Tetris!

Gene Expressions: Very dynamic, but didn’t understand a word. Cyrus gets the prize for blatantly ignoring the timekeeper.

Teaching CS: Great presentation. I’ll never read LiSP the same way again.

R6RS: Nicely presented, but it really did make Scheme seem the amateur little brother of Common Lisp. Square brackets? Case sensitivity?

Next 700 Libraries: I found this fascinating, but it seems some people have missed the point: it is a message of great optimism to demonstrate that automated assistance in the conversion of existing, substantial, documented and test-enhanced Java libraries is feasible.

Day 3

CL-HTTP: A report from a piece of the lisp world which seems to have been becalmed for the last 10 to 15 years… Very odd.

SC: S-expression-based C. Excellent slides. Who knew the future of C was sexps?

Crosscuts: A nice presentation, not least for introducing me to “the tyranny of the dominant decomposition”.

Inter-domain Network Management: Key point: rewriting everything in Lisp was the only way of reducing the errors introduced by the C and Perl modules.

CL-SNA: Next year’s ECLM in Istanbul should be a blast.

DAUTI in Scheme: Using such standard Scheme facilities as structs and macros, it took the author three evenings to get this going. Why so long?

Classification: Bayes meets Shannon. Probability meets belief. Umm, OK.

LispWorks Demo: And here’s one I made earlier. Frankly, it didn’t make me jump out of my seat (or some other appropriate Simon Cowellism…)

Dynamic Memory Management: A highly accomplished presentation from someone who really understands both the subject and the state of the art. Impressive.

ALU meeting: I will pass over this except to say (i) Europe and the ALU seem to be going their separate ways, and (ii) Rusty, I voted for you!

Day 4

HOP: Highly professional presentation backed up by 2-300k lines of scheme code. Something to explore one day.

Racer OWL: Description Logics are different from Object Orientation. Or Ontological Orientation. Or something.

List Comprehensions: LOOP!

CLforJava: Might have been better to take his own advice and not explain CLOS and MOP to the group. (Geoff — what’s wrong with “close”?)

Google SoC Lunch: Everyone hates Kenny…

DADTs: I missed the beginning of this, so it rather passed me by.

XMLisp: AgentCubes is very pretty. Which can’t be a bad thing…

Extensible Sequences: Five implementations and counting. Christophe dealt nicely with some heckling from the pensioners’ seats.

Liskell: Sexps are good for what ails you; Haskell means not having to write tests; and some very cute examples.

Scalable Lisp Applications: Some of this was interesting, but I came away with an impression much like Luke Gorrie’s, I’m afraid. (Now there’s a smart guy.)

Of course, the really cool stuff happened outside the conference room. But that’s another story.