Hello,
> 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).
I suspect networking might require a significant amount of work to
actually implement a fairly complete API, unless one is lucky and is able
to implement it on top of an existing interface for the implementation.
For example, take read-line. If I remember correctly SBCL's read-line
will signal a simple-error on EOF (unless told to return some special
value). This to me is unacceptable in the context of a unified
networking library; any I/O errors should be signalled using
conditions that fit properly into a logical hierarchy. Now, I have not
actually checked whether this error is signaled by read-line itself,
or by some grey stream generic function. If the latter the behavior
can be modified, but otherwise one would have to modify SBCL itself to
get the wanted behavior. The problem becomes worse if this situation
arrises with a non-free CL.
That particular example comes to mind because I had an issue with it
recently, but there are bound to be other things that are difficult to
solve by simply wrapping around the implementation's existing API.
I suspect one might have to design a completely independent I/O
interface, and provide as good compatibility as possible with the
native CL:s stream interface. In other words, code aware of the
unified library might use that API to get the full benefit of it, but
in cases where one needs to produce a grey/simple stream (e.g.,
wrapping the native stream) that should also be possible.
(Or am I alone in being willing to accept a departure from CL:s
standard streams?)
> 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...
I agree. I was mostly referring to a unified API for the usual
primitives like mutexes, conditions and thread creation. While it is a
no-brainer to write some conditional code for specific CL
implementations when writing your application, it is something that
should be unified from the start. A newbie should not have to know 6+
CL implementations by heart to get such a basic thing right. ("Basic"
in the context of concurrency.)
Unfortunately many CL:s do not support threads, or support a crippled
variant of them, or only support threads on some platforms. One would
have to provide some standard way of finding out whether the
concurrency part of the API is supported (rather than actually trying
to add concurrency support to a CL which does not support it, which,
as you say, is not just a matter of some library code).
--
/ 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
