It has been repeatedly and voluminously proposed that a cadre or cabal be formed to create a neolisp sublanguage -- a sanctioned set of add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe for obvious reasons.) I tend to agree with those who think that this needs to be done in public by a semi-formal elected committee. But I'm not much for talk. Therefore, I propose that we simply form the committee and start putting together the addons. What would have to happen is:
1. Create a sourceforge project. (I already have one that we could co-opt temporarily). 2. Elect the committee who create a charter. 3. Create a web site. (I run a server that we can use for free temporarily.) 4. Create a process, like the Python PEP process for proposal to be considered. 5. Do it.
#2 seems to be the most problematic, so I propose the following process:
2a. We set a target number of members, say 5. (Of course, anyone can help, but there needs to be a reasonable non-even voting block to make decisions.) 2b. Anyone wishing to become a member write a short self-promoting note. 2c. There is a period of voting through email to me. 2d. I'll tally the vote. (Anyone who has stood for election can review the raw vote email trail.) 2e. The top n (default 5) win. 2f. Those 5 worry themselves about the charter, which will presumably include how to change membership, etc.
I'll start setting up the web site, and those wishing to stand for election should register with me (just send me email), including writing your self-promoting bio (1000 word limit, please) by the end of this month.
The vote will take place for one week (7 days) beginning on May 1. We will begin the development effort mid-May.
JShra...@gmail.com wrote: > It has been repeatedly and voluminously proposed that a cadre or cabal > be formed to create a neolisp sublanguage -- a sanctioned set of > add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe > for obvious reasons.) I tend to agree with those who think that this > needs to be done in public by a semi-formal elected committee. But I'm > not much for talk. Therefore, I propose that we simply form the > committee and start putting together the addons.
Just for the enlightenment of the clueless, what happened to this effort? http://clrfi.alu.org/
I'd agree we need something like this (I suppose I'm part of the voluminous proposals you refer to) but it needs to be well structured, well organized, and have the active support of enough of the Lisp community to have moral authority. Probably the best way is to create good proposals. Also, perhaps the commercial Lisp vendors would have some interest in such a process, as well as the resources to do high quality work?
JShra...@gmail.com wrote: > It has been repeatedly and voluminously proposed that a cadre or cabal > be formed to create a neolisp sublanguage -- a sanctioned set of > add-ons (NOT replacements) for Common Lisp. (I prefer the term CADRe > for obvious reasons.) I tend to agree with those who think that this > needs to be done in public by a semi-formal elected committee.
Most wildly successful open source projects have a BDFL (benevolent dictator for life) that keeps things focused and moving forward at a good speed. You don't elect a BDFL, he emerges because he is doing something so kick ass that others want to be a part of it.
While popular, the term BFDL is really a misnomer. It would be more accurate to call Linus, Larry, Guido et. al. prophets rather than BFDLs. Any Joe can climb to the top of a hill and preach a sermon. When a true prophet preaches, people gather round. People begin to follow. If the leader loses his chops then folks lose interest and move on.
Of course in the technical realm, "preaching" means creating useful working code.
If you yourself are not a prophet and you can't find a prophet you want to follow then you need to learn to make due with the status quo (e.g. pick a CL implementation) and get on with your own work.
"C Y" <smustude...@yahoo.com> writes: > Just for the enlightenment of the clueless, what happened to this > effort? http://clrfi.alu.org/
Some people took the CLRFI idea and tried to define a process which would give them work, which they didn't do, so the process stopped.
In my opinion, in this time of web and wiki, the CLRFI could just be posted and commented in cliki.net, without a need for a central "authority", at least until some momentum is gained and resources agregated.
For example, useful libraries like CFFI could be posted as a CLRFI.
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any manner whatsoever, will increase the amount of disorder in the universe. Although no liability is implied herein, the consumer is warned that this process will ultimately lead to the heat death of the universe.
Oh. Right. Sorry. I forgot that we'd all agreed to to just sit around in church and pray for the nth coming ... Oh, and to dis any proposal to organize the community into collective action. Forgive me... (What page were we on in the hymnal?)
"Have you ever been in a relationship?" Attorney for Mary Winkler, confessed killer of her minister husband, when asked if the couple had marital problems.
JShra...@gmail.com writes: > Oh. Right. Sorry. I forgot that we'd all agreed to to just sit around > in church and pray for the nth coming ... Oh, and to dis any proposal > to organize the community into collective action. Forgive me... (What > page were we on in the hymnal?)
That's an interesting perspective. An individual with no obvious credentials comes along and proposes to do something that's been done in the past to little avail (cf. CLRFI) and which, in the minds of many Lispers, may or may not even be a worthwhile goal. The community largely ignores this individual and somehow this is proof that there is something deeply wrong with the Lisp community. Go away.
Pascal Bourguignon <p...@informatimago.com> writes: > For example, useful libraries like CFFI could be posted as a CLRFI.
They could, but I think that this would be a bad idea: libraries like CFFI are unstable in the sense that their interface is changing as new requirements are being discovered. What might make more sense to submit as a CLRFI is some interface to the low-level operations that CFFI uses to implement itself: operators dealing with things like C pointers, pinning vectors against being moved by garbage collectors, and similar. Bonus points if these operators are required by more than one 'userspace' library, so that one can judge the semantics needed against more than one use case.
