- Chris Double: "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." -- There's a long lag with SRFIs between the standards appearing, and their being incorporated in language implementations, but for library SRFIs the expectation is that the best will become standards and the others can be supported in an appropriate package system.
- Dave Roberts gives a nice summary of why lightweight, open language processes are good.
- I posted a story on LtU; hopefully it attracts interesting comments;
- And for the sake of completeness, François-René Rideau doesn't like the CLRFI name...
And some things that I guess would have been less inflammatory than what I did put in my last CLRFI wishlist...
- A good regexp library, perhaps modelled on Olin Shivers' SRE proposal, which I think is in tune with the CL approach (perhaps they should be renamed LREs?);
- XML reader/writer, perhaps along the lines of SSAX (as I think S-XML is);
- UNIX job control (so far missing from the SRFI process);
- An evaluation of approaches to type inferencing for Common LISP (in order to avoid misunderstandings, this is not the same as asking for CL to become strongly typed; also missing from the SRFIs).
... and crhodes on me on CLRFIs
crhodes writes (this and all following quotes):
Well, the goal of evolving Common Lisp isn't, or shouldn't be, to turn it into something which looks and quacks just like the fashionable duck of the day.Quite, but a CLRFI need not be judged by a timeless standard. If a CLRFI is very useful in the next five years, but after that is regarded as a dead-end, it may still be a worthwhile standardisation effort, if that effort isn't so great and the standard does create short-term benefits.
Scheme needed the SRFIs to allow people to decide on a shared vocabulary for completely ordinary programsI won't argue with this, but scheme is getting benefits from the process that go beyond making up for its inhibited language stadardisation process. I'd cite SRFI 40 as an example, but perhaps it won't appeal to all the hard-noses out there. Incidentally, the SRFI process has given rise to a new core standardisation process for scheme.
a brief perusal seems to indicate that most of the implemented SRFIs are essentially replicating the standard Common Lisp ``library''FWIW, it's a reqirement of the SRFI process that all SRFIs must be implemented to be finalised. What you say is more or less true of about 1/3 of the final SRFIs, but I think if you look more closely at many SRFIs that on the surface appear to be replicating CL are in fact doing stuff that goes beyond CLtL2.
Would adding these features instead encourage people from other communities to leap on the Common Lisp bandwagon? I think that's unlikely: why accept Common Lisp with Schemey bits tacked on if you already have Scheme?Thinking of bandwagons is maybe not for the best: if I'm on a bandwagon, I'm on the scheme bandwagon, but I read and code CL, and I think highly of the language. I'd like to hope that CL standardisers spare a thought for the interests of the periphery CL universe as well as for the stalwarts.
- Continuations It's too late now, I suppose, to say I thought twice about putting first-class continuations on my list, but then later thought that if we were to document one-shot continuations, we may as well document multi-shot continuations as well...
So a Scheme adept might bemoan the lack of full multi-shot re-entrant continuations, while ignoring (or being ignorant of) the fact that requiring such effectively kills off any hope for compilation to efficient code.Thus do myths arise... It is well-established that writing good, correct, optimising compilers in the presence of continuations is not easy. The possibility of reentrant continuations makes some useful optimisations fail, but one may always apply these optimisations if one knows these jumps cannot occur. Furthermore, most optimisations can be adjusted to cope with the presence of continuations. There is less justification for the claim that code with first-class continuations cannot be efficient than for the claim that code with implicit memory management cannot be efficient.
there is no demand from people currently using Common Lisp for these features.Well, Jeffrey Mark Siskind, author of the CL Screamer constraints package, left CL for scheme precisely because he wanted first-class continuations. There are advantages to having first-class language support for features you make heavy use of, a point that CLers usually are not slow to make when arguing with schemers. I'd identify this kind of problem domain (marrying CL with intensively backtracking logic programmingish constructs) as a key demand point for call/cc in CL.
there are portable libraries for achieving single-shot continuations, or macros enabling a natural expression of continuation-passing styleWRT to single-shot continutations, standardising rival approaches to language constructs is one of the key things one would hope to achieve with the CLRFIs. Using CPS to model continuations has its drawbacks, namely it is difficult to optimise this code, and typically one cannot represent non-call/cc based control constructs, such as dynamic-wind, in them.
Call/cc potentially interacts with many Common LISP facilities, nailing these down would be hard work, but the kind of work that is the point of language standardisation.
Just to make clear, the point of suggesting a CLRFI for Common LISP is not to suggest that call/cc should be implemented on all Common LISPs, only to point out that call/cc is in principle compatible with CL semantics and CL as a whole may benefit from some implementations having support for continuations. Furthermore, a value of the SRFI process has been to document difficulties that certain language constructs present for certain implementations: this kind of open standards process doesn't just map the road ahead for the core language, it also helps expose the existence of niche implementations and their attendant constituencies.
Postscript: Just recalled a quote from Kent Pitman that nicely characterises the nice but too costly school of thought on call/cc:
> Combined with the fact that there seems to be no real need for
> continuations in the "real world" , it's really hard to justify
> the inclusion of such a feature.
I don't know if I'd go so far as to say no 'need' in the sense of 'no use'. There is call for them, and they could be handy if we had them, but the price is too high. And if we offered call/cc in the way I propose, it probably would just annoy the Scheme community. Hmmm.... (sound of wheels turning)
- Hygienic macros By comparison with call/cc, having a standard library for hygienic macros in Common LISP does not really have a downside. There is a standard technology, SYNTAX-CASE, that is strictly more expressive than the SYNTAX-RULES style macros of R5RS scheme, and Common LISP's DEFMACRO (more expressive in the sense that it cannot be expressed be either, but can be used to define both).
Hygenic macros in Common Lisp would be a solution to a non-problem: given the years of experience in programming in the language (not my years alone: other people's years too) it is clear that the lack of hygiene in the macro system is simply not an issue to the Lisp community.I'm aware of this but, judging from c.l.l., beginners often run into hygiene problems in their early attempts at macro writing, and the CL house style for writing semi-hygienic macros is more complex to write than the scheme approach. There is, as far as I can see, no down side to having hygienic macros available to CL, if it is achieved by means of SYNTAX-CASE.
Postscript: There's a good, short, introduction to the problem of trying to define in a USENET message, Message-ID: <email@example.com>, by Will Clinger.
As for #! support, it's really not clear to me why that should need to be available in a standard fashionAre you doubting the value of #! invocations for scripting, or for having a CLRFI standard for dealing with them. WRT the first, they are convenient, I use them heavily with scsh (though it may be worth noting that the Tcl community seems to deprecate them). WRT the second, the discussion leading to SRFI-22 brought out some non-obvious issues with existing implementations; this kind of issue raising is a key advantage of these kinds of open standardisation processes and I hope they so prove for Common LISP.