Home

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!

By Charles A Stewart at 2004-10-06 02:09 | General | other blogs | 9220 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

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.

By Dirk Gerrits at Wed, 2004-10-06 12:16 | login or register to post comments

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.

By Charles A Stewart at Wed, 2004-10-06 14:25 | login or register to post comments

*FEATURES*

The site also contains a fairly good source of information about the CLRFI process. In particular, this page has something to say about your question.

Basically, the *FEATURES* mechanism which already exists in ANSI Common Lisp is used to check for CLRFIs. (So there is no real need for a SRFI-0 or SRFI-7 equivalent.) Each accepted CLRFI will have a number and a name. If a certain CLRFI is supported by your implementation, then the *FEATURES* variable will contain the symbols :CLRFI-number and :CLRFI-name where number is the CLRFI's number and name is the CLRFI's name. So you'll be able to check whether the featurep CLRFI is supported by just inspecting *FEATURES*: 

(if (member :CLRFI-1 *features*)
    (print "It's supported.")
    (print "It's not supported."))
Or you could do the same thing at read-time instead of run-time, by using the standard ANSI Common Lisp #+ and #- syntax: 
#+:CLRFI-1 (print "It's supported.")
#-:CLRFI-1 (print "It's not supported.")
(And similarly for :CLRFI-featurep instead of :CLRFI-1)

Note again that this is all standard ANSI Common Lisp and has absolutely nothing to do with the trial CLRFI. The trial CLRFI just describes a convenient function to do run-time inspection of the *FEATURES* variable. It would allow me to write (featurep :CLRFI-1) instead of (member :CLRFI-1 *features*). You could easily write FEATUREP yourself (see the reference implementation), and it's use is not limited to checking for CLRFIs. For example, (featurep :ieee-floating-point) (or (member :ieee-floating-point *features*)) checks whether your implementation "purports to conform to the requirements of IEEE Standard for Binary Floating-Point Arithmetic."

By Dirk Gerrits at Wed, 2004-10-06 15:16 | login or register to post comments