On Thursday, December 15, 2005, at 09:03 pm, Peter Schuller wrote: --->8--- snipped --->8---
> > I heard about cl-gardeners and I think it is a great idea. Personally > I am primarily interested in creating a unified generic library > portable across CL implementations. This is something I truly miss > from the Java world. I would like to help create a CL library that: > > * Includes a wide range of API:s that cover many of the usual things > you might expect from a modern language. At the top of my personal > list is networking, concurrency, and a reasonable level of OS/POSIX > integration. > > * Is well-documented, including error handling. > > * Is coherent. Is maintained, released and supported as a singular > entity. > > * Provides high-level abstractions rather than thin wrappers around > an underlying API. > > * Is release-engineered with a definite effort made to make sure all > supported CL implementations continue to work (long-term goal). > > In short, I would like a library which, in conjunction with a > supported CL implementation, is enough to start writing real > applications. > > Reading past posts on this list I get the impression there are at > least a couple of people with similar goals. I would like to try to > actually get started working on something like this. Does anybody want > to get together on it? Should things like this be worked out right > here on the ML, or should we try to keep the details off list and then > ask for feedback once there is something to show? > I'm interested in this goal too; the only thing that scares me in your list is support for concurrency. All Lisps as far as I am aware provide some kind of support for networking and OS integration, or at least FFI capabilities; wrapping these in a consistent, abstract API *shouldn't* be too difficult (famous last words, I know a couple of people have had a stab at this already, and of course for sockets there are a couple of networking libs with this goal already). Concurrency on the other hand seems to me to be something that the underlying Lisp either supports or does not support. Ensuring thread safety is something I don't believe can be accomplished in a library. The best I think that can be hoped for is that we're able to wrap threading functionality in an abstract API that degrades sensibly in the face of a non-threaded Lisp (or alternatively, hope that the 'major' Lisp without threads gets them PDQ and sack off any others. I'm not sure the number of others won't be equal to 0 anyhow once CLISP gets thread support). As long as the rest of the API doesn't depend on threading I don't see this reducing the usefulness of such a library (and I can't off the top of my head think of any library functions even for networking and OS integration (or GUIs) where threads are *essential* (there's always the fallback on fork() / exec() afterall I guess)). Perhaps this is what you were meaning in any case. Apologies for pointing out the obvious if so... -Duncan > -- > / Peter Schuller, InfiDyne Technologies HB > > PGP userID: 0xE9758B7D or 'Peter Schuller > <[EMAIL PROTECTED]>' > Key retrieval: Send an E-Mail to [EMAIL PROTECTED] > E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org > > _______________________________________________ > Gardeners mailing list > [email protected] > http://www.lispniks.com/mailman/listinfo/gardeners > _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
