opening it up with Common Lisp

Favorite weblogs

Lisp Related

Bill Clementson

Finding Lisp

Lemonodor

Lispmeister.com

Planet Lisp

Politics

Orcinus

Talking Points Memo

This Modern World

Working for Change

Other home

Polliblog

Recent Readings

Book review: Darwinia
Reviewed: Friday, August 11, 2006

Summer reading: Spin
Reviewed: Saturday, August 5, 2006

Runner
Reviewed: Tuesday, July 18, 2006

the Omnivoire's Delimma
Reviewed: Wednesday, July 12, 2006

the Golem's Eye
Reviewed: Wednesday, May 31, 2006





tinderbox
 width=

A few potshots at Eastwood
Wednesday, September 22, 2004

Yesterday I wrote a few notes on a putative Common Lisp Lint I've dubbed Eastwood. Christophe Rhodes sent me an e-mail proving that I'm not nearly the subtle thinker I think I am [smile]. It's not that Eastwood is a bad idea, it's just that my examples were either too glibly presented or just downright bad. I'll try again:

  • Unbound exported symbols. Christophe points out that there are a lot of reasons to export unbound symbols: "It could be part of the syntax of a macro, or a method combination qualifier, or a slot initarg. It could be a documentation type, or a type name. Not to mention an unbound special." I could pretend that I had thought of all these and elected to ignore them for ease of presentation, but that would be lying. On the positive side, however, this is an even better example of why Eastwood needs to treat each warning as a persistent object so that the lint process becomes a dialog rather than a monologue. I still think that unbound exported symbols are usually a mistake so I want my tool to question me once, let me tell it I know what I'm doing and then get out of the way. This opens up a lot of other issues surrounding what conditions should cause Eastwood to re-issue a warning you said to ignore, etc. But it's more fun to set your initial goals high!
  • Doubly-non-destructive functions. Firstly, my example was terrible since #'append doesn't necessarily copy its final argument. I knew that but overlooked it in my haste. A better example would have been (remove-duplicates (mapcar ...)). On the other hand, Christophe also points out that "... consing is not the universal badness that one might assume: consider the effect of a GC occurring after the APPEND and before the REMOVE-DUPLICATES. The result of the APPEND is not garbage, so it's moved into a higher generation, and protected with a write barrier. If you DELETE-DUPLICATES, you will hit the write barrier, invoke a kernel trap, unprotect the page, and will need to do extra work at the next GC; if you REMOVE-DUPLICATES, no writing to old generations is involved. So the consy version could easily end up being faster, in this special case at least." I can't say that I've always wanted to learn about the innards of garbage-collect strategies but this sort of deeper interaction is definitely a reason to.
  • Mistyped function names. Here, at least, Christophe is in complete agreement with me -- one for three is pretty good in baseball. He points out that SBCL already style warnings for this sort of thing. I think that SBCL's style warnings are a good idea and they are definitely a subset of the sort of things that I think Eastwood to notice. The problem with SBCL is that every warning is, in essence, treated with the same level of repetitious urgency. This is true for many of our interactions with computers: "Are you sure you want to quit?". If we see the same warning or dialog over and over again, we learn to ignore it without thinking. As far as I know, this general UI issue hasn't been solved beyond the advice to reduce the number of dialogs and make every operation reversible. I believe that general solutions will require tools with significantly more intelligence and ability to learn than has been the norm. It also requires the sort of subtle and deep thinking that Christophe displays.

|

Home | About | Quotes | Recent | Archives

Copyright -- Gary Warren King, 2004 - 2006