On Friday, December 16, 2005, at 08:04 pm, Peter Schuller wrote:
> 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.
>
Well... that is the specified behaviour for READ-LINE, according to the
hyperspec...
> 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?)
My guess is that you are ;-) I don't believe its impossible to
create a (very) useful network library on top of CL streams -
especially if Grey is taken as a given.
Whilst it might be out of scope for a Gardener's project, I
personally think we should go the LispM route in a library of
this kind and integrate pathnames and network transports back
together; then it would be possible to get back the natty
host / transport negotiation type stuff that was done on that
platform.
This is a longer-term goal for me, and one that is dependent on
networking libraries that deal in terms of strictly CL-type
streams (i.e. ones that can be used by the standard CL methods
that operate on 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.)
>
There is already compatability code for a bunch of this simple stuff in
with McCLIM; depending on the license that ends up being used this can
probably be recycled usefully as a library in its own right (although
again, I think several people have thought about this before - Dan
Barlow being one, some of his musings may well be found on Cliki).
> 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).
I don't know of any Lisps that support MP that don't push something onto
*features*. All we need do is provide '*threaded-p*' which
examines the appropriate feature for the underlying Lisp I guess. That
said, several of the methods you'd expect to find in an MP library could
degrade gracefully into non-threaded code; some suggestions for these
can be found in the CLIM 2 spec:
http://mikemac.com/mikemac/clim/clim-sys.html#32.2
... although whether this is a good API for a natively threaded Lisp
or not I'm not sure (many of the methods listed make less sense when
the Lisp is not process / stack-group based I think).
Perhaps some time should be taken to document the interfaces that
existing
threaded Lisps use (I can only think of four:- LispWorks, Allegro,
OpenMCL
and SBCL on x86) and compare them.
-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
