First time poster on this forum... so for some background I have been using common lisp for about three years now, but nothing too intensive. It is certainly the lisp language I know the most and indeed the programming language I know the most (done a bit of elisp and had a brief foray with LUSH recently... that taught me just how much I have been conditioned by common lisp and also just how convenient common lisp is). I have used a couple of languages (the usual suspects C/C++, java, bit of fortran and read about others python, ruby) and since Lisp has captured my heart, none of the others have been able to peel me away from it. I imagine the same is true of most people here; lisp seems to be quite polarising.

Well, at the moment I am using common lisp for some numerical simulations. Common lisp has got alot of libraries, but in a way very similar to linux, nothing seems to work painlessly; there's always something missing, broken or incompatible with your implementation or whatever. Recently I have had a look at some of the other lisps out there and, whilst they definately have their merits, these merits are not enough to sway me from common lisp (yet...). To reiterate what seems to be common opinion:

Scheme: small, tidy, consistent and with some specific features (its a lisp-1, continuations)Common Lisp: HULKING BEHEMOTH-meaning lots of libraries, lots of variety but also lots of confusion. Although the lisp standard is very solid, its like they just standardised everything going (and it they did indeed, in an effort to get everyone on board). Good implementations, used in industry et cetera.Clojure: Runs an java VM (good/bad), seems to be quite neat/focussed in its design, interact with java libraries. Arc:Seems to have a fresh, clean look on things. Alot of dead weight seems to be removed with this, but is too much being removed?

This is just a brief list of somethings I have seen said about it or my brief first impressions on things and I would like to disclaim the above and say that I certainly haven't reviewed them thoroughly. Also, there are other things like picolisp, newlisp, LUSH and whatever that I have missed.

Now, it certainly seems that Common Lisp has a lot of luggage. There are inconsistencies in function names and whatever. Nothing is to stop you from simply avoiding these things or working around them and that is certainly possible with a language like lisp. A number of people/groups (as mentioned above) have tried to make their own new versions of lisp, often in an attempt to get away from this issue, however it seems to be to be a shame to waste all of the time, effort and goodies packed into lisp. On the other hand, it would certainly be desirable to get the language into shape. The common lisp standard seems to be too old now to expect any drastic additions/changes. People complain that the programming world has moved on, but CL is still stuck in the past, with the counter arguments "Yeah, but it was way advanced for its time" or "you can implement these new things with macros".

Lisp is certainly one of the best (if not, the best) language for customisation and flying solo, however it can't be denied that it's better to getting help from other humans, whether that is through collaboration or libraries - it is a shame for people to put in so much hard work and be themselves the only benefactor (from a programmer sense, not a user sense).

So, what if a new community standard was made that was bolted onto common lisp to exploit all of the hard work already done, take advantage of libraries et cetera, but was its own "standard" in a way, shedding any unnecessary baggage picked up throughout common lisps life time and inception. To clarify, things like sort being destructive, odd predicate names (and the sheer number of predicates), these thing would be shed or superseded. The language could be made tighter and more consistent. Certain parts of CL's standard would not be present in this new, refined standard. However certain other things, that were simply considered libraries, would now be considered part of the standard.

This might seem pointless, but my point is, that a fresh, new, redesigned standard would be easier/more attractive to learn, bringing in more fresh meat and keeping the veterans happy. It would also encourage a more similar/consistent programming style amongst people - for instance if you wanted to use sockets, you wouldn't implement your own or pick one of a number of libraries, because the standard one is already there - this would improve the sharing of content (and hard work) and also me that time could be concentrated on actually getting things to work. Individually, we can build a house, but together we can build pyramids (incidentally, why don't we build pyramids or towers of babel anymore?).

I believe it is important to provide a standard, but have it evolve faster than what the CL standard is currently able to. Python and Ruby seem to shed their skin/(get recut?) every new version (from what I have read.... No experience with these languages...). To this end, I would think that it would be best if a comittee was set up to regulate what went in (with some sort of overly complex voting system...) and what went out of releases. But it is important that this it would be a community project. There seem to be a lot of solitary lispers in the wild creating code that noone will ever see (and there must be some great ideas out there also). If this code and ideas could be amalgamated in a controlled way, then we all (especially those like me, with inadequate lisping skills) would all benefit.

Of course, there are libraries like CLOCC which have approached this from a different angle (i.e. a library) but I think a new standard would be a better mentality (anyway, CLOCC could just be stolen...). The fact that it would be inherently compatible with CL would require discipline, ofcourse, as there is nothing to stop people from using non-standard things from the rest of CL. The requirement is on the programmer to set out with the mindset of creating code conforming to the new standard.

So what are your thoughts on this? If such a thing was started, would you support it? Ofcourse, there are many pitfalls, and, as with everything community driven, there is a potential for it to never gain momentum or fizzleout eventually. There are very many lisp dialects, but I think the things that would set this apart would be its community driven nature, fast evolution and its grounding in CL (at least initially, one could imagine it going its separate way, if successful enough). On the other hand, it could languish in indirection, never getting anywhere because of so many opinions. At least, this is what the comittee would be for.

tldr: clean up common lisp, new standard, community driven, new functionality

IMO, throwing away the standard just to rename a few functions isn't a good idea. Cleanning up CL by adding features won't work. Cleaning up CL by making it community driven is a contradiction in itself.

To justify a new common lisp the community had to come up with serious new language design ideas like Clojure did. But i cannot see that for CL.

I don't think that the problem of CL is that it's not clean enough. Its as clean as a seriuos language can be. The problem is that CL is mispercieved as a language playing in the Phyton league while its in fact designed to play in the C++ league. Put a Phyton programmer in front of a C++ compiler and you will hear even more complaining. But the Phyton programmer wouldn't demand a redesign of C++ because he knows that C++ is playing in a different league. But put a Phyton programmer in front of CL and he will claim that CL is "broken" because he percieves CL as a bloated version of Phyton.

Yeah, CL should be newly standardized, because of the implementation-dependent treatment of passed arguments to the program, FFI and MOP, etc. CL's standard is deprecated, but Python isn't standardized at all, it works in other way in Python's world. Because of a friendly/ordinary look it has a huge userbase, therefore a lot of libraries, a dynamic evolvement and also people which make Python's environment working as it's working. On the other side there is CL with a tiny userbase*, so there is a small effort to do such things like a consolidation or better said there isn't even enough to consolidate.*This forum can serve as an evidence, it's perhaps only one for lisp (It's my observation from searching about lisp on the internet) and here is a low rate of activity and preponderantly it's kind of activity, when someone signs up here, asks once about basic stuff, gets the solution and after that never returns, I think, just few visitors of this forum use lisp persistently.

A parallel initiative is Fare's library consolidation project, which is a significant part of what you are looking for. If there was a coherent core of libraries that actually worked reliably it certainly would make life easier ( how many testing frameworks are there? How many csv reading libraries and so on). I don't think that actually changing the standard will get too far, but cleaning up the Eco system is something of value.

And on your note of numerical simulations some of us are engaged on thinking about building a numerical lisp substrate if you are interested.

@Konfusius - no I don't think the standard should be discarded as such, but used as the basis for something better, perhaps? I do see your point with regards to playing in the C++ league, practicalities do seem to get in the way of perfectionism and also there is the success of Good Enough.

Yeah, CL seems to have amalgamated with a lot of ideas since it was first conceived (well even whilst it was being conceived). Certainly something like a standardised FFI would be useful. A big reason for these things being standardised is simple reliability. Implementors must take time to ensure that these things work. As it is, there are tonnes of libraries for this and that, so you spend time thinking about which is the best for you to use/fits your mentality, but in the end you are forced to just try them all in the hopes that one will work, or try to fix one. It is interesting that python does not have a standard. So is it simple done on a per version basis? Cram whatever you can into it and release it to the wild?

Thanks for the mention about the CDR... I have not heard of this before, which does not perhaps bode well for the project? If I understand correctly, they will accept any document provided it is up to their standard of quality? The only thing with that is, we will still be stuck with vast swathes of libraries/approaches, only they will be specified veeeerry precisely...

Fare's project would indeed do pretty much what I am talking about, good find! I think it could work quite well, provided it gains the momentum. It seems the lisp community needs to get together and jump on the same bandwagon to forge something good. Also, things seem to need more publicity? This seems like a good idea, but difficult to stumble upon whilst grooming the internet. Perhaps I am overestimating the size of the lisp community? As Goheeca says, this forum stands as evidence to the size of the lisp community - and I believe its only been running for four years... It seems comp.lang.lisp and stackoverflow are the other gathering places, and I don't think they do too well in forming a "community".

Yes, I would be interested in a numerical lisp. As I say, I tried lush out and tried to port some code that I am currently using to it, but in the end got frustrated with some of the syntax and felt homesick for CL. I am not saying that it lush isn't good, certainly some things in it are better for numerical simulations (after all, that's what it was built for) and there are alot of features in it, considering the small work force. In the end I decided to get busy with some macros to make my own environment in CL. What is the scope for this numerical lisp you are talking about? Would it be a numerical library or contain some data management tools? I've got some things I want to implement for data management/manipulation - once (if?!) I get it going (and if it's good enough) I'd be planning on sharing it somehow.

This thread pops up every once in a while (hey! *I* popped it up a few years ago). Problem is, the notion of "community driven" is ill-defined and it leads to the Python 2.x-3.x thingy.

My 2 cents opinion? The CDR is the best effort so far. There is a clear and simple model for discussing proposals and the proposals are there for implementors to adopt. Let's not forget that CL is NOT a single-implementation language. Fare's proposal is also interesting, but why not stick to the CDR? The CDR is mostly interesting because it does not discuss libraries. It discusses specifications, which are far more useful.My - undoubtedly self-serving - take on the CDR is that there are not many contributions because writing well rounded specifications, even for "simple" things is very difficult. Of course, YMMV in your definition of "well rounded".