Planet Lisp

François-René Rideau: Next Boston Lisp Meeting: Monday September 29th 2008, 6pm at MIT 34-401B

Sun, 07 Sep 2008 00:00:25 -0700

NB: ITA Software, a fine employer of Lisp hackers (disclosure: I work there), is kindly purchasing a buffet to accompany our Monthly Boston Lisp Meeting. Anyone who attends is welcome to partake. We appreciate it if you let us know you're coming, and what food taboos you have, so that we can order the right amount of food. Tell us by sending email to boston-lisp-meeting-register at common-lisp.net. We won't send any acknowledgment unless requested; importantly, we'll keep your identity and address confidential and won't communicate any such information to anyone, not even to our sponsors.

Rich Hickey will give a 90' talk about Clojure.

Clojure http://clojure.org/ is a dynamic programming language that targets the Java Virtual Machine. It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

Rich Hickey, a New-York based software engineer, is the principal author of Clojure.

* *

The Lisp Meeting will take place on Monday September 29th at MIT, Room 34-401B.

As the numbers indicate, this is in Building 34, on the 4th floor.

MIT map: http://whereis.mit.edu/bin/map?selection=34

Google map: http://maps.google.com/maps?q=50+Vassar+St,+Cambridge,+MA+02139,+USA

Many thanks go to Alexey Radul for arranging for the room, and to MIT for welcoming us. I unhappily won't be able to attend for personal reasons, and I thank Richard Kreuter for accepting to be our Master of Ceremony.

* * *

The previous Boston Lisp Meeting on July 21st had only 30 participants. Jay McCarthy's presentation was excellent, and though his code wasn't Lisp, the spirit of it was exactly the kind of Metaprogramming that is dear to Lispers.

We're always looking for more speakers. The call for speakers and all the other details are at http://fare.livejournal.com/120393.html

Please forward this information to people you think would be interested. Please accept my apologies for your receiving this message multiple times.

For more information, see our new web site boston-lisp.org. For posts related to the Boston Lisp meetings in general, follow this link: http://fare.livejournal.com/tag/boston-lisp-meeting or subscribe to our RSS feed: http://fare.livejournal.com/data/rss?tag=boston-lisp-meeting

John Wiegley: Too much good stuff

Fri, 05 Sep 2008 20:00:35 -0700

A rundown of some of the cool things I’ve been playing with lately, which have distracted me from blogging...

Gary King: hack? features. asdf. enh?

Fri, 05 Sep 2008 08:03:00 -0700

I use timeouts in lift (so that you can stop run-away tests) and in trivial-shell (so that you can stop run-away processes). Both systems have included the file with-timeout.lisp and since my god hates duplication of error, this has long gnawed at the dark toast of my soul.

Thus is born trivial-timeout. So far, perhaps good. But (there has to be a but or why post) I don’t want trivial-shell or lift to depend on other systems: test frameworks should stand on their own (a dubious premise but one I hold) and trivial things should carry their own weight. How, then, can I get three systems to play well together without making my own life too painful?

As is my habit, I decided to leap to the first idea that came to mind (so that I can write about it and suffer the slings and arrows of outraging rivers). What I wanted to be able to do was say “Yoh, system, don’t load this file if some condition holds”. This is kinda/sorta what features are for so I thought that something like

...
(:module
  "timeout"
  :pathname "dev/"
  :components 
  ((:featurep-source-file 
    "with-timeout"
    :feature (not :com.metabang.trivial-timeout)))) 
...

would make sense and make it clear that the system should only (compile|load|whatever) the file “with-timeout” if the feature :com.metabang.trivial-timeout was not present in the *features* when it came time to (compile|load|whatever) it.

Since this isn’t part of ASDF, I added the following to my system defs:

(unless (and (find-symbol (symbol-name 'featurep) '#:asdf)
       (fboundp (find-symbol (symbol-name 'featurep) '#:asdf)))
(defun asdf::featurep (feature-expression)
  ;; thanks to Richard Kreuter for the initial implementation 
  (when feature-expression
    (etypecase feature-expression
      (symbol
       (member feature-expression *features*))
      (cons
       (let ((bool (intern (car feature-expression) 
         (load-time-value (find-package :keyword)))))
         (ecase bool
           (:and
            (every #'asdf::featurep (rest feature-expression)))
           (:or
            (some #'asdf::featurep (rest feature-expression)))
           (:not
            (not (asdf::featurep (cadr feature-expression)))))))))))

(defclass featurep-source-file (cl-source-file)
  ((feature :initform nil
      :initarg :feature
      :reader feature)))

(defmethod perform :around ((o load-op) (c featurep-source-file))
  (when (asdf::featurep (feature c))
    (call-next-method)))

(defmethod perform :around ((o compile-op) (c featurep-source-file))
  (when (asdf::featurep (feature c))
    (call-next-method)))

This may not be beautiful, but it does work.

A few notes:

I do know about in-order-to ( ... (feature ...)) but this doesn’t seem to have quite the right semantics (or perhaps I just understand the semantics!)
Currently, I’ve copied the code into three system files but I’m going to arrange for it to live in one place and get copied around as part of my make process.
I’d load to hear of other better (or, what the heck, worse) ways to accomplish this task. Don’t disappoint me!

Enjoy the fall.

Gary King: reality based reporting

Thu, 04 Sep 2008 09:55:10 -0700

This piece from the AP goes out on a limb and actually checks some facts. Just when you thought that reporting was all and only about what people said, someone notices that the best model of the world is the world itself (thanks to Rod Brooks for that last).

Hope springs eternal.

Paul Khuong: SWAR implementation of (some #'zerop ...)

Tue, 02 Sep 2008 23:54:37 -0700

SWAR (SIMD Within A Register) codes can portably express short-vector parallelism for operations on small packed data (e.g. byte or even nybble vectors). A trivial application of the technique is when we test whether any bit in a word is set (equal to 1) by comparing the whole word against 0. Obviously, that also work to test whether any field (of arbitrary width) is not filled with 0. This document, from 1997, provides a fairly clear and complete overview.

Just like testing whether any bit is set, it is easy to find whether some bit is not set (it's simply the opposite of whether every bit in the word is set). Things are more complex when the data are wider than a single bit (but obviously narrower than a full word). I found a short implementation (and barely tested it), but it might be possible to do even shorter. Skip to the series of asterisks if you want to solve that puzzle (to efficiently find whether any field in a sequence of data, itself packed into a single word, is 0) yourself.

To simplify the description, I'll assume that we're working with 4-bit-wide fields. It should be clear how the code can be adapted to other widths or even mixed widths.

Let x = aaaabbbbccccdddd... be the input.

1. x' = x | (x >> 1). The first bit in each field is now, for our purposes, noise. However, some of the remaining 3 bits are now non-zero iff some the original 4 were.

2. ones = x' & ~0x8888.... The noise bits are masked out.

3. borrow = 0x8888... - ones. The first bit of each field in borrow is 0 iff some of the 3 other bits in ones aren't (iff some of the 4 bits in x weren't).

4. result = borrow & 0x8888... is zero iff the first bit of every field in borrow is 0 (iff every field in x was non-null).

And, finally, that is easy to test for, a word at a time. In the end, it takes 5 (hopelessly serial) operations (>>, |, &, - and &) and a conditional branch.

**** Testing whether any field in a word is filled with 0 may seem incredibly obscure. Apart from (some #'zerop [packed-unboxed-vector]), what use is there for such code sequences? One trick is to exploit xor. xor lets us compare multiple fields at a time: a field is 0 in a xor b iff the corresponding fields in a and b are identical (bit for bit). Now that we can determine when at least one pair of fields is equal, it's simple to implement, e.g., default FIND on specialised vectors without having to test each datum separately (until the very end, when we know that one of the pairs is equal, but not which). As usual, a full implementation, capable of dealing with :start, :end and displaced vectors is a lot more work.

Zach Beane: the dependency dance

Tue, 02 Sep 2008 19:54:31 -0700

I'm working on a simple S3 client. I just finished grabbing all the deps and sub-deps I need:

alexandria.asd
babel-streams.asd
babel.asd
cffi-grovel.asd
cffi.asd
chunga.asd
cl+ssl.asd
cl-base64.asd
closure-common.asd
cxml.asd
drakma.asd
flexi-streams.asd
ironclad.asd
puri.asd
split-sequence.asd
trivial-features.asd
trivial-gray-streams.asd
usocket.asd

It was tiring. I am looking forward to the glorious future of Lisp distribution systems.

Geoff Wozniak: Slowly working through LiSP

Tue, 02 Sep 2008 05:55:06 -0700

As of Friday at around 11:30 a.m., I officially have the degree of Doctor of Philosophy. To celebrate the end of an era for me, I spent the weekend relaxing with my wife at the lake. Oh yes, and I worked through the first chapter of Queinnec's book.

Just for fun, I'm translating as much of the code to Common Lisp as I can, although continuations could prove challenging. Since it's a spare time project and I don't have the guilt of having to finish a thesis hanging over me, I don't mind. If the Scheme to CL translation doesn't work out, I'll at least have to port some old Scheme code to new Scheme code.

I should get around to posting the thesis in HTML format later this week, for those interested^*. At the very least, a PDF version will make an appearance.

^*Amazingly, a couple people have said they want to read it! One of my colleagues said recently that a good thesis should collect dust (since it is the point from which new research starts), meaning no one should read it. Here's hoping that violating this maxim doesn't mean the thesis is worthless.

Gary King: Announcing: some Lisp software updates! (finally)

Mon, 01 Sep 2008 11:54:35 -0700

I’ve been wicked busy the last many months and the pace of my life looks to continue along the same tack (and in the same vein, even). That said, I really appreciate bug reports and patches and I will get them in something less than sidereal time so please keep ‘em coming).

trivial-http : 1.3.0

Fixed lame HTTP GET sending HTTP HEAD requests (ack!). Also added a user-guide (well, let’s be honest and call it the start of a user guide) and did some minor tweaking of all things. Progress.
cl-containers : 0.10.3

Bug fixes to dlist-containers and other tweaks.
[metatilities-base] : 0.6.4

Aside from the unexciting pathname-without-name+type; there is nothing to see here.
moptilities : 0.3.10

Mostly bug fixes to docstrings.

Note that nothing should be read into the odd inverse version numbers for moptilities and cl-containers :-)
trivial-shell : 0.1.10

Brought in Stephen Compall patches (thanks!); did some documenting and other minor cleanup. Finally exported get-env-var.

Enjoy.

Luís Oliveira: The features of Common Lisp

Thu, 28 Aug 2008 18:01:32 -0700

Abhishek Reddy has compiled an interesting list of Common Lisp features. It's quite concise and includes examples for almost every feature described. It'll come in handy next time someone asks you what is it that attracts you to Lisp.

Geoff Wozniak: Behavioural synthesis, the (Lisp) thesis

Thu, 28 Aug 2008 18:01:32 -0700

On August 18, I successfully defended my PhD thesis entitled Structuring data via behavioural synthesis. I explored the idea of deriving data structure for objects in a system by examining the behavioural aspects of a system. I did all the programming for the work in Common Lisp and did three things in the thesis to demonstrate how behavioural synthesis can work.

The first was a framework for defining data types whose instances can change their internal structure to accommodate different conditions related to their usage. This is done at the individual object level. It allows for highly adaptive objects, but incurs significant overhead. This demonstrated using limited context to control structural changes.

The second approach used this framework to expand the contexts detected. In particular, I showed how you can define data types that are the union of other data types, possibly with intersecting interfaces. By considering where an object is created in the code and what is on the system stack, code is generated to capture this context. By putting the context directly into the code, the overhead of detecting the conditions in the objects is removed.

Finally, I demonstrated a more open-ended approach that offers up some interesting future work: building class hierarchies on-the-fly. The idea is to write programs without class definitions, but still use classes and objects. I augmented a Lisp system to handle three cases: no class defined, no slot defined and no method found. Using various clues, I come up with a class hierarchy and try it out. There are various limitations to the approach (no surprise!) but it's really interesting and worth some future study. That said, there are certain conditions where it produces reasonable class hierarchies.

The external examiner on the thesis was Richard P. Gabriel, who asked some good questions and gave me some ideas with what to do next with the work. In general, I got the impression the examination committee liked the work, even though it was imprecise in some areas. There are only some minor revisions to make before officially submitting it to the university.

I'm in the process of making the code available — it needs some serious clean-up in places — along with a tech report of the work. When I have the revisions complete and its been submitted to the university, I'll post a copy of the thesis online. Some may be interested in the introduction and literature survey. (One examiner said I should look at publishing the survey.) The more ambitious can dive into the technical elements.

Geoff Wozniak: Queinnec's book, at last!

Thu, 28 Aug 2008 18:01:32 -0700

As a gift for successful completion of my thesis, a friend of mine gave me a copy of Queinnec's book, Lisp In Small Pieces. If I had this book earlier, I probably would have finished my thesis a lot later.

ECL News: Project: automated testing of libraries with ECL

Thu, 28 Aug 2008 18:01:32 -0700

Dear lispers,

this message is for not only for ECL users looking for a place to contribute, but also for developers of libraries that want them to be tested with our implementation of Common Lisp.

We have reached a point where the ANSI compatibility test suite is not enough. Undocumented or undefined behavior that changes between releases may cause some libraries to break in unexpected ways -- we have plenty of messages in the mailing list about them.

So my idea is to add new directories to ecl-test for automating the downloading and testing of other libraries on a daily, weekly or monthly basis, depending on how things move on.

As a guidance you may have a look at how ecl-test/ansi is implemented: Makefile checks for the existence of that directory and otherwise checks out with cvs a fresh new copy of the test suite. Tests are then loaded and run, and the output is logged into output/ecl/ansi.log. We could have similar directories for cffi, babel, flexi-streams, and other packages. It should not be that difficult.

However, given that this is to be run on at least five different platforms, a few restrictions apply:

1) Source code can only be retrieved using cvs, ftp or wget/curl
2) Running the tests should not take more than half an hour on a computer with few resources: 512Mb, P4 (this is a typical configuration for my virtual machines)
3) The test suite should be comprehensive enough.
4) If possible, libraries should not have other dependencies.
5) One should only test stable releases.

If neither of these points is satisfied, then I do not see the point on going any further. However, not all restrictions are equally important. Points 1 and 3 are crucial, and 3 most so: why running a test suite when it is not able to produce a meaningful answer? Point 4 is not so relevant. If it cannot be satisfied by all libraries then the design might become a bit more complex. Point 5 can be negotiated: libraries that wish to be tested before release could be configured to look for an almost stable branch of the code.

What I provide is a rather powerful computer (quad-core, 64 bits, 8GB), running kvm with at least the following virtual machines:

* Windows XP + Microsoft Visual Studio 2008
* Ubuntu Linux 64bits
* Fedora 32bits
* FreeBSD
* NetBSD
* OpenBSD

Interested parties should contact us at the mailing list.

Juanjo (0 comments)

François-René Rideau: GHARF

Thu, 28 Aug 2008 18:01:32 -0700

As previously announced, I've started my own business. If you're looking for a software company that develops distributed reflective systems, look no further.

Our purpose will be to develop the ideas from the TUNES project, starting with the low-hanging fruits in the hope to fund our longer-term goals.

Our long-term goal is to use reflection (internalization of the knowledge and expertise of computing semantics) to improve semantics-based unification between programming languages, and otherwise push ever higher the level of abstraction at which programming may happen.

The low-hanging fruits, we think, still lie in better automation in the development and management of distributed computing systems, particularly so as regard the building of systems consistently manipulating large bodies of evolving persistent data.

We hope to build as our flagship product a database system that scales semi-automatically. Declarativeness, syntactic and semantic abstraction, will allow for faster development as well as easier management. Unlike existing "relational" or "object" databases, we will decouple the data model from the transaction model, allowing for enhanced robustness as well as unequalled flexibility in adapting the database to various application domains. Based on a relatively efficient dynamic higher-order typed language, and maintaining an explicit decoupling between monotonic (purely functional) and linear (stateful) fragments of our computational logic, we'll build a distributed system, a reliable multicast facility on top of which we can journal distributed transactions, that can be used to construct various queryable views of the data.

Our first version will probably extend and productize Erlang-in-Lisp, reuse Mnesia, and possibly combine these techniques with Elephant, BKNR or another such existing system to persist objects. Further versions may or may not be displace Common Lisp with Scheme, Factor, Javascript, or our own COLA, for total semantic control allowing for metaprograms that aid with code-data co-evolution.

All software will of course be Free Software, published under a dual license bugroff/MIT, and available on TUNES.org. You'll be welcome to use it, improve on it, and either give back to the community or stubbornly hoard your improvements. But if you need the world best specialists to tailor our software to your needs, build robust and usable applications, and provide exceptional service, then you know where to find us.

TUNES.org will continue to pursue its existence as an independent non-profit organization. Our company will be a separate for-profit entity that happens to contribute to the TUNES project. We are open to research and/or development contracts, with the understanding that our core software will be published as free software, although special-purpose customizations might remain an unpublished secret shared with our customers.

The current codename for our company is GHARF (rot13), though this name is neither marketable nor available in .COM. We have several ideas for an actual marketable name, but will refrain from announcing anything until we have secured the internet domain registration and setup an initial web site.

Cusp Development: Making a small Common Lisp Project (in Cusp)

Thu, 28 Aug 2008 18:01:32 -0700

In honor of my recent addition to Planet Lisp, and as a special thank you to Xach, I figured I'd counter-blog his old post on how to make a lisp project (in Slime). You can go read that if you want. Here's the Cusp way:

Make the project. Go to New > Lisp Project. Enter the name of your project. You're done.

Write the code. You'll notice that a file named "main.lisp" has been opened for you. Put your lisp code there. You can compile the definitions as you write them (with Alt+C), but that's mostly a vestigial holdover from Slime. Cusp is smart. Save your file and it will automatically compile any new or changed top-level forms. (It'll even undefine functions that you've deleted.)

Later on... If you close Cusp, when you come back you'll need to reload the project. To do this, right-click on the .asd file in the project, and choose "Load Project." You may also need to change the package in the REPL to match the one for this project.

So what is all this stuff?

You've got all you need to start hacking, but you probably want to know what's going on behind the scenes. The New Project wizard creates a project folder with three files in it: main.lisp, defpackage.lisp, and [project name].asd. Here's what they do:

main.lisp is the main code file. Put the guts of your program here. You can, of course, create additional files as your project grows. More on that in a moment.

defpackage.lisp defines the package for this lisp project, which is basically the lisp equivalent of a namespace. You could pollute cl-user with your project internals, but that's just asking for trouble down the line. You'll note that main.lisp started out with (in-package :[project-name]). You'll want to make sure any new files you add start that way, too.

If you want to import symbols from another package into your project (so you can say split rather than cl-ppcre:split) put the name of that package into the :use section. This is similar to using in C++ or C#, or import in Java. If your project turns into a library to be used by other projects, you would put any exported symbols into the :export section. Notice that by default, you are already importing :cl.

[project-name].asd is best thought of as your project file. This tells Lisp what libraries to load up for your project, and what files are part of your project. You'll notice that defpackage and main are already listed in the :components section. If you add more files to your project, make sure to tack them on to the end of that list. Files will be loaded in the order they are listed.

Dependencies are also handled by the asd file. If, as in the earlier example, you want to use cl-ppcre, make sure to add it to the :depends-on section.

Asd files can get more complicated if you need, but this should be enough to take care of you in 95% of all cases. Happy hacking!

Lispjobs: SBCL guru sought (Alphacet)

Thu, 28 Aug 2008 18:01:32 -0700

Rosario M. Ingargiola of Alphacet writes:

SBCL Guru Sought

We are looking for a consultant that has experience working with SBCL. The initial project is as follows:

1. Show us how to use the foreign function interface in SBCL to access C and FORTRAN via .so dynamic library files.

2. Build a simple framework for loading and calling external libraries from SBCL (pre-loaded code we write and third-party libraries; not looking for automatic glue generation just hooks to make the process easier)

3. Create build and deployment mechanisms for this part of our product which installs multithreaded SBCL and our application CL code.

There would likely be other projects depending upon experience. Working remotely and moonlighting is okay. Please contact rosarioi@alphacet.com

Zach Beane: l1sp.org

Thu, 28 Aug 2008 18:01:32 -0700

Inspired by p3rl.org, I've just created l1sp.org.

It has very little content of its own. Instead, it's a redirect service that provides relatively short, memorable URLs for index entries for a variety of Lisp software.

For example, you probably can't remember that the URL for section 11.1.2.1.2 in the hyperspec is http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm. But now you don't have to! You can just link to l1sp.org/cl/11.1.2.1.2 instead. You can also link to symbols or format directives if you like.

A number of other projects are indexed. The current list includes cl, ccl (for the Clozure CL manual), cffi, clim, clisp, clx, sbcl, and hunchentoot.

This isn't a search service, it's for when you know the project and symbol you're looking for, and want to get to its documentation quickly. For search, try lispdoc.com.

L1sp.org is new, and will evolve. I don't recommend making l1sp.org URLs a permanent part of your software's documentation, for example. But I hope the service will be handy if you are chatting with a friend and want to easily point to some documentation.

If you have a suggestion for or question about l1sp.org, let me know.

Tim Ritchey: TRUENAME issues? Check your links

Thu, 28 Aug 2008 18:01:32 -0700

I've been trying to get Paragent up and running on my laptop for DEMO, and was having a bunch of TRUENAME issues that were pointing to locations in ~/.sbcl/systems/. It turns out I had accidentally forgotten the -s when linking the asd files for a couple projects. Oops.

Tim Ritchey: OS X, SBCL and SLIME, Oh, My!

Thu, 28 Aug 2008 18:01:32 -0700

I ran into an issue with the latest SBCL and SLIME on OS X this morning, where I was getting a screenful of the following:

WARNING:
   Releasing #S(SB-THREAD:MUTEX
                :NAME NIL
                :%OWNER NIL
                :LUTEX #), 
  owned by another thread: NIL

this thread has a workaround that gets things back to some normality. I still get the odd dropout when running under slime and compiling UCW. In particular, the whole setup doesn't appear to like Hungarian, as I pretty regularly get a dropped connection to *inferior-lisp* and it is always at the line: compiling (DEFUN HUNGARIAN-PLURAL-OF ...).

Once DEMO is off my plate, I may have to seriously sit down and see if there is anything I can do to make my favorite operating system, and my favorite CL implementation get along.

Andy Hefner: Interval sequences

Mon, 18 Aug 2008 23:32:04 -0700

Lately I've done some programming in Factor, and one feature I've grown fond of is that integers are considered sequences, usable with map and other combinators. As an excuse to take the extensible sequences protocol for a spin, I implemented this in CL (or really SBCL, since I don't think any other implementations have implemented extensible sequences).

The extensible sequences protocol requires that sequences be subtypes of the SEQUENCE class. I didn't like this at first, wanting to implement sequences directly on integers, but soon decided that wrapping things up in a class wasn't so bad - I can just write (below n) instead of n, and it suggested that I go a little further and implement intervals as sequences. Using the constructors below and interval, I can write the following:

(map 'vector 'list #(a b c d e) (below 3)) => #((A 0) (B 1) (C 2))
(map 'list '1+ (interval 20 25)) => (21 22 23 24 25)

Only a few definitions are needed to make this work:


;;; Interval sequence class

(defclass interval-sequence (sequence standard-object)
  ((minimum :reader minimum :initform 0 :initarg :minimum)
   (length  :reader sequence:length :initarg :length)))

;;; Constructors
  
(defun below (n)
  (unless (>= n 0)
    (error 'type-error
           :datum n
           :expected-type '(integer 0)))
  (make-instance 'interval-sequence :length n))

(defun interval (min max)
  (unless (<= min max)
    (error "Interval minimum must be less than or equal to maximum"))
  (make-instance 'interval-sequence :minimum min :length (- max min)))

;;; Core sequence protocol

(defmethod sequence:elt ((interval interval-sequence) index)
  (with-slots (minimum length) interval
    (unless minimum
      (error "Attempt to read from an uninitialized interval"))
    (when (or (< index 0) (>= index length))
      (error 'type-error
             :datum index
             :expected-type `(integer 0 ,(1- length))))
    (+ index minimum)))

(defmethod (setf sequence:elt) (new-value
                                (interval interval-sequence)
                                index)
  (with-slots (minimum length) interval
    (cond
      ((or (< index 0) (>= index length))
       (error 'type-error
              :datum index
              :expected-type `(integer 0 ,(1- length))))
      ((null minimum)
       (setf minimum (- new-value index))
       new-value)
      ((/= new-value (+ minimum index))
       (error "Incompatible setf of interval element - expected ~A, got ~A"
              (+ minimum index) new-value))
      (t new-value))))

(defmethod sequence:adjust-sequence ((interval interval-sequence) length 
                                     &key; initial-element initial-contents)
  (declare (ignore interval length initial-element initial-contents))
  (error "Interval sequences are immutable"))

(defmethod sequence:make-sequence-like 
    ((interval interval-sequence) length
     &key; (initial-element nil iep) (initial-contents nil icp))
  (declare (ignore initial-element initial-contents))
  (when (or iep icp)
    (error "Can't create intervals using initial-element/initial-contents."))
  (make-instance 'interval-sequence :minimum nil :length length))

An odd bit above is the notion of uninitialized sequences (where length is known, but not the minimum) and the behavior of (setf elt). Intervals are considered immutable, but (setf elt) is permitted provided it would not change the sequence. It is also permitted when minimum is unset, in which case it completes initialization by setting minimum to (- newvalue index). Intended to support initialization of intervals by map, this allows a neat trick:

(map 'interval-sequence (lambda (x) (+ x 7)) (below 5)) => #<INTERVAL-SEQUENCE [7,12)>

I thought there was some chance that remove would just work in the case where the element is on an end of the interval. It doesn't. The reason is that generic remove is implementing by calling delete on a copy of the sequence. As there is no way to distinguish destructive operations on a full copy during initialization from any other time, it seems like any immutable sequence has a bit more work to do in implementing the (non-destructive) utility functions.

I've filed my implementation away here in case anyone is interested.

Lispjobs: Compiler jobs at Hengsoft (Palatine, IL)

Mon, 18 Aug 2008 10:09:42 -0700

From comp.compilers:

Date: Thu, 14 Aug 2008 11:07:36 -0500
From: Frank Weil <frank.weil@hengsoft.net>
Subject: Compiler jobs at Hengsoft (Palatine IL)

The Software Design Automation group, a core part of Hengsoft LLC, a
newly formed company with operations in Palatine, Illinois; Kiev,
Ukraine; St. Petersburg, Russia; and Tianjin, China; is hiring to fill
full-time research and development positions for its Palatine
location.

The group’s focus is the automatic transformation of high-level
specifications into efficient, product-quality code and the
development of supporting tools written largely in Common Lisp. This
transformation is driven by a knowledge base of both general-purpose
and domain-specific programming techniques. The current system has a
development history of more than 10 years and has successfully been
applied to produce code shipped in a number of commercial
telecommunications products.

Responsibilities of these positions include the identification and
codification of domain-specific optimization and implementation
schemes, their integration into the existing code-generation
framework, and the development and testing of resultant
compilers. Experience in one or more of the following areas would
therefore be valuable:

* Lisp programming
* Optimization techniques
* Program derivation
* Algorithm derivation
* Partial evaluation
* Type inferencing
* Datatype refinement
* Parallelization / Serialization

Necessary skills include an understanding of implementation and
optimization techniques that go beyond mere programming experience,
and the ability to codify such knowledge in order for it to be applied
to specifications. Strong programming skills and modeling skills in
UML or SDL are helpful as well. We currently do not have specific need
for parsers, lexers, or back-end compiler techniques as a main
expertise.

If your strengths lie in one or more of these (or related) areas and you
are interested in working in a dynamic and highly productive
environment, please send your resume to:

Dr. Frank Weil
Hengsoft LLC
1530 E. Dundee Road
Palatine, IL 60074 USA

e-mail: recruiting@hengsoft.net
fax: (847) 327-3896

(Thanks, Rainer Josweg)

Ingvar Mattsson: 18 Aug 2008

Mon, 18 Aug 2008 06:08:53 -0700

Here, marnanel writes about early mornings and it resonated.

Due to an assortment of reasons, my primary "I am alone, there is no external pressure" hacking time tends to be from not-too-long after 6 am (depending on how promptly I can get up and go through the normal first-things-in-the- morning routine), until about 07:30, when it's time to finish getting dressed and head towards the train station, for another exciting day in the office.

That's also the first time period of the day when I can check my email and do a brief check on assorted web stuff. Most, if not all, of my coding is accomplished in these 45-80 minutes of the day. At times, I am surprised I get anything finished...