It seems that using ANSI to make new standard is unadvisable. The process is cumbersome and there are copyright issues with ANSI.
If there is need to revise the standard. Common Lisp folks can for less byrocratic organization to do it. Library standardization can happen organically.
Instead of just standardizing what is out there, the committees become self-serving; they keep meeting just for the sake of keeping the committee going, and begin inventing things for others to implement.
That X3J13 got the job done and then dissolved is very, very respectable.
---
This is the reason we have bloatware.
Without a standard, it seems most efforts to build a new Lisp come to a naught (think Racket and Clojure and Arc and ...)
The standard was great for removing incompatibilities between all of the old competing Lisps, but now that all of the implementations are on the same page and support the base line standard, I don't see the point in updating and revising the standard.
Is there really anything to add that couldn't be done as a library? And while there are warts, it's easy enough to avoid those parts or use macros and libraries to smooth over them. There may be some undefined behavior or implementation specific things in the standard, but it's far less than C or C++, and facilities like the features list makes it pretty easy for libraries to detect implementation differences and do the right thing.
> Without a standard, it seems most efforts to build a new Lisp come to a naught (think Racket and Clojure and Arc and ...)
Seems like a non sequitur. There are plenty of languages without standards that have become popular (Python, Perl, Java, Ruby, Go, etc.) and also plenty of non-Lisp languages that don't have standards and have gone no where. And then there's ILisp, which has a standard and has still gone basically nowhere.
I'd like to see outstanding issues noted in the existing standard to be resolved.
For instance, there is one ambiguity in unwinding. Unwinding occurs under the locus of a dynamic control transfer which has selected an exit point. Unwinding can be intercepted by a form like unwind-protect. That form can "hijack" the control transfer by initiating another one, possibly to a different exit point. The question is: what exit points are still visible and hence available when a given unwind protect cleanup block is executing? Can the unwind-protect choose a less distant exit point than the original control transfer?
ANSI CL basically leaves this aspect nonportable: when an unwind protect cleanup is executing, it could be the case that all of the exit points which were "on the way" to the current exit point are already "torn down". Or it could be the case that the implementation performs "tear down as you unwind": exit points are torn down as their binding forms are terminated during unwinding.
In a nutshell, it is implementation-defined whether to tear down intervening exit points during the original search for the exit point, or leave them up and take them down during the actual unwinding.
The latter behavior is probably less surprising and should probably be ANSI CL standardized.
I have two things I wish were in the standard:
* I wish the abstract syntax generated by backquote were standardized. This would permit backquote forms to be used for pattern matching in something like Optima.
* I wish there were a standard coroutine mechanism, that could be used for CLU-style iterators (aka Python generators). Although threads can be used for this, the context-switch cost makes it undesirable to do so.
So it's not that hard to come up with examples of things we would like to have added or clarified. But I think they're things we can, after all, live without.
Yes. One example is tail call elimination. Without that being standardized, programmers are dissuaded from writing recursive code. And it can't be added with a library.