Bill Clementson had an interesting write-up about some of the things discussed recently at the Amsterdam Lisp User Group meeting. Among them was the proposal to create a Common Lisp Request For Implementation (CLRFI) process that would facilitate the evolution of Lisp without having to drag everybody into a heavyweight standards body like ANSI.

I suggested something along these lines a few months ago, and the idea has only gotten more firmly etched in my brain the more code I write in CL.

For example, I have been playing around with some amount of network application code. Just about every CL implementation supports a different network interface library. That's just painful. When I complained about this on c.l.l way back when, well-meaning people suggested that I write my own adapter library between some internal, private network API that I should design to whatever the specific implementation API happens to be. While that can be done, the problem here is that it's just painful. People said that I should keep separate in my mind the concepts of a programming language (Lisp) and anything that is OS-specific (like network APIs). The C programming language doesn't specify a network API, they said. Yes, that's true, but I have to believe that was mainly because when C was defined many machines didn't actually have network connections and most programs were not written to be networked. Clearly, the world has changed regarding networking capabilities in the last 20 years. However, C did, from it's earliest days, define a stdio library for file I/O (as documented in K&R). In any case, I'm a firm believer that modern programming languages need some standardized, basic infrastructure in order to facilitate the development of widely-interoperable libraries of application-level functions.

As Chris Double said on Planet Lisp (and why this isn't actually listed in his blog, I have no idea):

The problem I generally have isn't taking my Common Lisp programs and running them on other platforms. I rarely have to do this. It's being able to take other peoples library source and use it on whatever Common Lisp system I'm currently using. In practice though it's not that big a problem. There are defacto standards around for a lot of things and some very portable libraries. But if the CLRFI implementations could be shipped with the Common Lisp implementations themselves then there would be no porting necessary and that would be a great thing.

In any case, a lightweight process like CLRFI is perfect. Frankly, I understand the arguments where people say that going back to ANSI to extend CL is a mistake. I have dealt with many standards bodies over the years (including ANSI when I was working on FDDI) and the concerns are well-founded. For those that don't know and haven't been exposed to this, there are many types of standards bodies, from heavyweight to lightweight. ANSI is at the heavyweight end of the scale. It's the official standards body for the USA and is the member body representing the USA at ISO. This means lots of policies, procedures, and a general lack of speed. If you want to standardize something like power sockets, fine, ANSI is a great place. Knock yourself out. Fast-moving technology, it's a pain.

At the other end of the scale, we have something like SRFI or CLRFI: just a bunch of like-minded people putting out memos to each other, capturing good ideas and making sure they are recorded in a common location where everybody can know where they are. It's low-overhead and you can make a lot of progress very quickly. No, there's nothing to force anybody to comply with a memo posted on a certain web site, but you'd be amazed how just writing something down and putting some letters on it like "CLRFI" has the power to change things. It's funny that the IETF originally used to be very lightweight, just an organization for assigning numbers and publishing Request For Comments (RFCs) in an orderly way. As the Internet grew and the infrastructure became more important, the IETF started that gradual slide toward bureaucracy.

So, we'll see if the CLRFI idea makes much headway. Personally, I hope it does. I think that CL needs to start adding some basic infrastructure to itself in a standard way. Something like the CLRFI process could start that ball rolling. Who knows, if we're successful, in 20 years we may be as bureaucratic as the IETF is now. We should only be so lucky.