## CLRFIs

An open standards process for Common LISP was announced a couple of weeks ago at the Amsterdam LISP meeting, the ALU CLRFI standards process, apparently modelled on the Scheme SRFI. So far only one standard has been submitted, a features testing standard.

Open standards processes such as the CLRFI have the potential to be of general value to people interested in language design issues, since they can bring out a great deal of tacit wisdom about language and library features that is otherwise difficult to get hold of.

Curently there is not much information about the whys and whats of the CLRFI process, though Kent Pitman has argued for some time that Common LISP needs a SRFI-like program. More information awaits a hungry audience!

## Comment viewing options

### Two corrections and a call for input.

Firstly, the Lisp meeting in Amsterdam this news item refers to is the one on 26 September 2004. At the time of this writing, that's about one and a half weeks ago, and as far as I know, "a couple of weeks" is at least two weeks. ;-)

Secondly, no CLRFIs have been submitted so far. The "featurep" CLRFI that's on the site is only there for expositionary purposes at the moment. It should be going through the CLRFI process at some nearby point in the future.

Lastly, I'd like to ask everyone who's interested in the CLRFI to join the clrfi-announce and clrfi-process mailing lists. There are still some open issues before the first CLRFIs can go through the admission process, so if you have anything to say about this, please let your opinions be heard at clrfi-process@alu.org.

### CLRFI process

Thanks to Dirk's message, I at last found the clrfi-process mailing list, which is filled with information about the whats of the process, and I see an acknowledgement of the SRFI process has appeared on the front page.

And a question for Dirk: how does this first CLRFI compare with SRFI-0? Is it intended to convey a machine checkable assurance that a particular implemetation supports a given CLRFI? With srfi-0/srfi-7 using the srfi-# for testing machine support was criticised on the grounds that it caused headaches with the IETF RFC process when old RFCs were superseded, but implementations required conformance by naming the RFC.

### *FEATURES*

(if (member :CLRFI-1 *features*)
(print "It's not supported."))
#+:CLRFI-1 (print "It's supported.")
#-:CLRFI-1 (print "It's not supported.")