From: ············@mediaone.net
Subject: Free Linux Lisp and Sockets
Date: 
Message-ID: <3ab33c86.697234289@news.ne.mediaone.net>
I've read the notes about CMUCL and other lisps on Linux.
Two questions: 

Which of the free lisps has solid support for socket programming
(since this is always implementation specific)?

Which of the free lisps is best able to run allegroserve?
D. Tenny
············@mediaone.net - no spam please

From: Johannes Groedem
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <lz8zm4y93u.fsf@wintermute.copyleft.no>
············@mediaone.net writes:

> Which of the free lisps has solid support for socket programming
> (since this is always implementation specific)?

You can do socket programming with CMUCL just fine.

Check out ext:create-inet-listener, for example.

-- 
johs
From: Oliver Bandel
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <990dta$1in@first.in-berlin.de>
Johannes Groedem <····@spam-copyleft.no> wrote:
> ············@mediaone.net writes:

>> Which of the free lisps has solid support for socket programming
>> (since this is always implementation specific)?

> You can do socket programming with CMUCL just fine.

> Check out ext:create-inet-listener, for example.

I think this is no Standard-Lisp.

How is it documented?

Is CMUCL well documented?


Ciao,
   Oliver
From: Paolo Amoroso
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <Lbi0OqPllUgDVMGIlXLnQ1fQAPx8@4ax.com>
On 17 Mar 2001 20:28:42 +0100, Oliver Bandel <······@first.in-berlin.de>
wrote:

> How is it documented?
> 
> Is CMUCL well documented?

Most of the useful documentation on CMU CL has been collected in the
EncyCMUCLopedia--see the signature below. The currently available version
was released more than one year ago and is out of date, but I am working on
a new version.


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Tim Bradshaw
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <ey3k85oy21e.fsf@cley.com>
* my-last-name  wrote:
> Which of the free lisps has solid support for socket programming
> (since this is always implementation specific)?

LispWorks (including the free one) has everything I've ever wanted to
do with sockets -- basically an interface to waiting for TCP
connections on a port and an interface to open a TCP connection to a
port on a host.  This is enough to write a simple fairly minimal web
server for instance, but I guess would not be enough to do things like
check where the far end of a connection is coming from which would be
useful for a serious web server.  I imagine if you wanted hairier
stuff then you could ask, but probably not for the free one.

I suspect that ACL's interface is more comprehensive, especially since
it needs to run allegroserve which is probably more than what I'm
defining as a simple web server.

> Which of the free lisps is best able to run allegroserve?

I'd guess ACL.  Unfortunately in all the cases I'm interested in I
either want something like apache (seriously hairy and supports
x-random-non-lisp-interface) or something so simple I write my own
minimal thing alluded to above which I don't then have to learn, so I
haven't actually used it (though I'm sure it's good).

One thing is that if you want to do anything really useful,
multithreading really helps a lot, even for tiny servers, so you
probably want something with multithreading.  Of the really free ones
that may restrict you to CMUCL on Linux, which I think is now
multithreaded (?).

--tim
From: Pierre R. Mai
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <87k85os6ya.fsf@orion.bln.pmsf.de>
Tim Bradshaw <···@cley.com> writes:

> * my-last-name  wrote:
> > Which of the free lisps has solid support for socket programming
> > (since this is always implementation specific)?
> 
> LispWorks (including the free one) has everything I've ever wanted to
> do with sockets -- basically an interface to waiting for TCP
> connections on a port and an interface to open a TCP connection to a
> port on a host.  This is enough to write a simple fairly minimal web
> server for instance, but I guess would not be enough to do things like
> check where the far end of a connection is coming from which would be
> useful for a serious web server.  I imagine if you wanted hairier
> stuff then you could ask, but probably not for the free one.

You can easily get at the address of the peer of an inbound connection
using comm:socket-stream-peer-address, e.g.

(defmethod connection-address ((connection lwl-connection))
  (comm:ip-address-string
   (comm:socket-stream-peer-address (connection-stream connection))))

The area where you might get into trouble with LWW/LWL are probably
not things you'd encounter with HTTP, i.e. UDP support, raw-IP
support, advanced TCP options, etc.

Our in-house server has been trivially ported to CMU CL (MP and
serve-event implementations), ACL and LWW/LWL, requiring only around
50 LOC for each platform.  It should be trivially portable to all
other implementations that offer good CLOS support, and offer
some form of multi-threading and basic TCP/IP socket support.

> I suspect that ACL's interface is more comprehensive, especially since
> it needs to run allegroserve which is probably more than what I'm
> defining as a simple web server.

AFAIK ACL's socket interface allows you to gain fairly complete
control of BSD-style networking, though I'd guess Erik Naggum would be
more competent to comment on the state of ACL sockets.

There's also an alternate sockets interface for CMUCL/SBCL, by Daniel
Barlow (see http://ww.telent.net/lisp/sockets.html ), which gives more
complete access to the BSD sockets API.

> One thing is that if you want to do anything really useful,
> multithreading really helps a lot, even for tiny servers, so you
> probably want something with multithreading.  Of the really free ones
> that may restrict you to CMUCL on Linux, which I think is now
> multithreaded (?).

CMU CL does implement multi-processing on x86 (i.e. FreeBSD or Linux).

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Chris Double
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <wkzoelgqjl.fsf@double.co.nz>
············@mediaone.net writes:

> Which of the free lisps is best able to run allegroserve?

Does the Allegro Common Lisp trial for Linux run allegroserve? If so,
that may be a good choice.

Otherwise I don't know of any other lisp that runs allegroserve other
than Corman Lisp on Windows (see http://www.double.co.nz/cl for a
version of allegroserve that works).

Chris.
From: Vebjorn Ljosa
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <cy34rwtm1xp.fsf@proto.pvv.ntnu.no>
* Chris Double <·····@double.co.nz>
| ············@mediaone.net writes:
| 
| > Which of the free lisps is best able to run allegroserve?
| 
| Does the Allegro Common Lisp trial for Linux run allegroserve?

it does.

-- 
Vebjorn
From: ········@hex.net
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <x1Cs6.65663$lj4.1713184@news6.giganews.com>
Chris Double <·····@double.co.nz> writes:
> ············@mediaone.net writes:
>> Which of the free lisps is best able to run allegroserve?

> Does the Allegro Common Lisp trial for Linux run allegroserve? If
> so, that may be a good choice.

Not if you want to use allegroserve for more than "toying around"
purposes.  That's effectively what the ACL "trial" is intended for;
that's essentially the meaning of "trial."
-- 
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hex.net/~cbbrowne/lisp.html
So long and thanks for all the fish.
From: Christian Nyb�
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <87g0gcuye4.fsf@siteloft.com>
············@mediaone.net writes:

> I've read the notes about CMUCL and other lisps on Linux.
> Two questions: 
> 
> Which of the free lisps has solid support for socket programming
> (since this is always implementation specific)?
> 
> Which of the free lisps is best able to run allegroserve?

Before making a choice with regards to what implementation of CL you
want to choose, you may want to look beyond the trial versions and
check what you'll need to pay in case you want to set up a web server.
Some of the vendors have fairly optimistic expectations of the web's
revenue possibilities, and agressively want their bit of that
imaginary cake.
-- 
chr
From: Sam Steingold
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <uy9u1d89t.fsf@xchange.com>
> * In message <··················@news.ne.mediaone.net>
> * On the subject of "Free Linux Lisp and Sockets"
> * Sent on Fri, 16 Mar 2001 16:18:56 GMT
> * Honorable ············@mediaone.net writes:
>
> Which of the free lisps has solid support for socket programming
> (since this is always implementation specific)?

both CMUCL and CLISP do.
please see CLOCC/PORT/net.lisp
(<http://www.podval.org/~sds/data/port.html>) for a unified
cross-platform socket API.


-- 
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
From: David Bakhash
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <m366h3i1v3.fsf@alum.mit.edu>
Sam Steingold <···@gnu.org> writes:

> > * In message <··················@news.ne.mediaone.net>
> > * On the subject of "Free Linux Lisp and Sockets"
> > * Sent on Fri, 16 Mar 2001 16:18:56 GMT
> > * Honorable ············@mediaone.net writes:
> >
> > Which of the free lisps has solid support for socket programming
> > (since this is always implementation specific)?
> 
> both CMUCL and CLISP do.

I really like CLISP's socket API, but last I checked, I didn't feel
the same about CMUCL's interface.  I like a relatively low-level
interface (make-socket, accept-connection, close).

For this reason, ACL's interface is the best I've seen in Common Lisp.

dave
From: Pierre R. Mai
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <87ae6dk98s.fsf@orion.bln.pmsf.de>
David Bakhash <·····@alum.mit.edu> writes:

> I really like CLISP's socket API, but last I checked, I didn't feel
> the same about CMUCL's interface.  I like a relatively low-level
> interface (make-socket, accept-connection, close).

Hmmm, can you give some indication of what you didn't like about
CMUCL's interface.  It seems to me that it offers the low-level
interface you like (connect-to-inet-socket, create-inet-listener and
accept-tcp-connection, close-socket), as well as an FFI to the BSD
socket routines, and some higher-level stuff.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: David Bakhash
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <m33dc5vg3n.fsf@alum.mit.edu>
"Pierre R. Mai" <····@acm.org> writes:

> David Bakhash <·····@alum.mit.edu> writes:
> 
> > I really like CLISP's socket API, but last I checked, I didn't
> > feel the same about CMUCL's interface.  I like a relatively
> > low-level interface (make-socket, accept-connection, close).
> 
> Hmmm, can you give some indication of what you didn't like about
> CMUCL's interface.  It seems to me that it offers the low-level
> interface you like (connect-to-inet-socket, create-inet-listener and
> accept-tcp-connection, close-socket), as well as an FFI to the BSD
> socket routines, and some higher-level stuff.

Oh.  Last I checked there was this aweful `wire' business.

dave
From: Pierre R. Mai
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <87g0g4fx4b.fsf@orion.bln.pmsf.de>
David Bakhash <·····@alum.mit.edu> writes:

> > Hmmm, can you give some indication of what you didn't like about
> > CMUCL's interface.  It seems to me that it offers the low-level
> > interface you like (connect-to-inet-socket, create-inet-listener and
> > accept-tcp-connection, close-socket), as well as an FFI to the BSD
> > socket routines, and some higher-level stuff.
> 
> Oh.  Last I checked there was this aweful `wire' business.

Hmm, the WIRE stuff is still there, but it is actually not a socket
interface, it's the data-transport layer of an RPC mechanism (the
REMOTE package) between CMU CL processes.  It _uses_ the low-level
TCP/IP interface, but it was IMHO never intended as a general purpose
communication mechanism between CMU CL and the rest of the world, or
as a general purpose socket interface (that's what the low-level
interface is for).

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Rudolf Schlatte
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <lxitl6ro1t.fsf@ist.tu-graz.ac.at>
············@mediaone.net writes:

> I've read the notes about CMUCL and other lisps on Linux.
> Two questions: 
> 
> Which of the free lisps has solid support for socket programming
> (since this is always implementation specific)?

In addition to all the other answers, I would like to point out clocc
(<URL:http://clocc.sourceforge.net/>), expecially the "port"
subsystem, which provides an implementation-independent socket api,
among other things.  This provides an overview of the basic socket api
of many implementations.

rudi
From: David Bakhash
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <m3ae6fi1zj.fsf@alum.mit.edu>
Rudolf Schlatte <········@ist.tu-graz.ac.at> writes:

> In addition to all the other answers, I would like to point out clocc
> (<URL:http://clocc.sourceforge.net/>), expecially the "port"
> subsystem, which provides an implementation-independent socket api,
> among other things.  This provides an overview of the basic socket api
> of many implementations.

Not all of us like it, though.  Personally, I don't like the CLOCC
code for networking (or multi-threading, last I checked).

It's one of those annoying least-common-denominator things that
bothers me.  I guess it could have been done much better, but that's
just my opinion.  I'd not use it.

dave
From: Sam Steingold
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <u8zlxzk0h.fsf@xchange.com>
> * In message <··············@alum.mit.edu>
> * On the subject of "Re: Free Linux Lisp and Sockets"
> * Sent on Thu, 22 Mar 2001 15:14:00 GMT
> * Honorable David Bakhash <·····@alum.mit.edu> writes:
>
> Rudolf Schlatte <········@ist.tu-graz.ac.at> writes:
> 
> > In addition to all the other answers, I would like to point out clocc
> > (<URL:http://clocc.sourceforge.net/>), expecially the "port"
> > subsystem, which provides an implementation-independent socket api,
> > among other things.  This provides an overview of the basic socket api
> > of many implementations.
> 
> Personally, I don't like the CLOCC
> code for networking 

Could you please be more specific?
What is missing?
I always welcome constructive criticism!

-- 
Sam Steingold (http://www.podval.org/~sds)
Lisp is a way of life.  C is a way of death.
From: David Bakhash
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <m3ae6dvg5d.fsf@alum.mit.edu>
Sam Steingold <···@gnu.org> writes:

> > Personally, I don't like the CLOCC
> > code for networking 
> 
> Could you please be more specific?
> What is missing?
> I always welcome constructive criticism!

you got it.

My beef is mostly with the networking stuff in clocc.  It's easy
enough to use, but it's not well designed, in my opinion.

First off, you could have *designed* it the right way, and then had
the implementation do the correct translations under the hood.
Instead, the translations are done at read-time, and there is no
consistent implementation.  For example, what is a socket in your
code?  A class?  a struct?  a stream?  a number?  Can I define methods 
on it, in the general case?  NO.  Why?  because you can't use a
deftype as a method specializer.  So that makes your code annoying for 
use with CLOS.

The design I myself use is a simple, mostly efficient CLOS
implementation, where clocc/net:socket is a class, and there are
methods on it.  Had you implemented it this way, you could have used
the #+/- macros to determine the method implementation for each Lisp
implementation.  Instead, you have `socket-server-close'.  That could
(and should) have simply been the gf `close'.  Your function
`socket-string' could have been a print-object method on your class
definition.  For some Lisp implementations, you could even have had
your clocc/net:socket class subclass the underlying socket class
(e.g. LispWorks).

Lastly, this would have simplified the (future) interface of advanced
socket options avaiable in some implementations and not in others,
since the gf's would signal errors when called in an environment where
they can't do the right thing, and maybe that wouldn't be a serious
condition, necessarily, since those options are quite often for
optimizations that only beef up performance, etc.

If you want to know how it would look, then I guess it's a mixture of
(mostly) ACL's interface (functionally) and LispWorks's (class
design-wise).  I like ACL's interface, except with a class in place of 
a struct, and some other stuff.

dave
From: Sam Steingold
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <u66h0y0p4.fsf@xchange.com>
> * In message <··············@alum.mit.edu>
> * On the subject of "Re: Free Linux Lisp and Sockets"
> * Sent on Fri, 23 Mar 2001 02:29:09 GMT
> * Honorable David Bakhash <·····@alum.mit.edu> writes:
>
> Instead, the translations are done at read-time, and there is no
> consistent implementation.  For example, what is a socket in your
> code?  A class?  a struct?  a stream?  a number?

a stream.

> Can I define methods on it, in the general case?  NO.  Why?  because
> you can't use a deftype as a method specializer.  So that makes your
> code annoying for use with CLOS.

these was a discussion on CLOSifying net.lisp on the clocc-list in May
2000.  There appeared to be little support for this.
Franz declared they they are moving away from the Gray streams, so
apparently sockets should not use them "for future portability".

Also, right now `sockets' are built-in streams, so all stream operations
work on them without the CLOS overhead.

> Instead, you have `socket-server-close'.  That could
> (and should) have simply been the gf `close'.

first, not all supported implementations implement `close' as a gf.
second, a `socket-server' is not a stream, and IMO, `close' should be
used only by the streams.

If you want to use CLOS, you can do

(require "net")
(defclass socket-class (fundamental-stream)
  ((sock :type socket ...))
  ...)

This way all the implementation details will be hidden for you...

-- 
Sam Steingold (http://www.podval.org/~sds)
Just because you're paranoid doesn't mean they AREN'T after you.
From: David Bakhash
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <m3y9tw7t2c.fsf@alum.mit.edu>
Sam Steingold <···@gnu.org> writes:

> > Can I define methods on it, in the general case?  NO.  Why?
> > because you can't use a deftype as a method specializer.  So that
> > makes your code annoying for use with CLOS.
> 
> these was a discussion on CLOSifying net.lisp on the clocc-list in
> May 2000.  There appeared to be little support for this.  Franz
> declared they they are moving away from the Gray streams, so
> apparently sockets should not use them "for future portability".

This has nothing to do with Gray streams; it has to do with the socket
library, and I agree that sockets are not necessarily streams.

> > Instead, you have `socket-server-close'.  That could
> > (and should) have simply been the gf `close'.
> 
> first, not all supported implementations implement `close' as a gf.
> second, a `socket-server' is not a stream, and IMO, `close' should be
> used only by the streams.

What implementation doesn't?  As far as I know, CMUCL does, CLISP
does, ACL, LispWorks, and CormanLisp all do.  Which don't?

> If you want to use CLOS, you can do
> 
> (require "net")
> (defclass socket-class (fundamental-stream)
>   ((sock :type socket ...))
>   ...)

that's true, I suppose, but it's still LCD-style, and doesn't actually 
consider any of the implementation-specific stuff in _some_ of the
Lisp implementations, which was my main point.

dave
From: Sam Steingold
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <uvgp0hwyi.fsf@xchange.com>
> * In message <··············@alum.mit.edu>
> * On the subject of "Re: Free Linux Lisp and Sockets"
> * Sent on Fri, 23 Mar 2001 17:36:05 GMT
> * Honorable David Bakhash <·····@alum.mit.edu> writes:
>
> This has nothing to do with Gray streams; it has to do with the socket

I wanted SOCKET to extend FUNDAMENTAL-STREAM - how else can you make it
a class _AND_ an stream?

You do want to be able to use `read-line' on socket, do you?
Well, you can now, but if I defined sockets as a class,
I would require Gray stream support to make the usual stream operations
available for sockets.

> library, and I agree that sockets are not necessarily streams.

_sockets_ (AKA 'active sockets') _are_ streams.
_socket-servers_ (AKA 'passive sockets') are _NOT_.

> > first, not all supported implementations implement `close' as a gf.
> > second, a `socket-server' is not a stream, and IMO, `close' should be
> > used only by the streams.
> 
> What implementation doesn't?  As far as I know, CMUCL does, CLISP
> does, ACL, LispWorks, and CormanLisp all do.  Which don't?

GCL.  And CormanLisp appears to lack gray streams.

ALso, right now, `close' does close a socket, and it should not close a
socket-server, so this is a non-issue.

> > If you want to use CLOS, you can do
> > 
> > (require "net")
> > (defclass socket-class (fundamental-stream)
> >   ((sock :type socket ...))
> >   ...)
> 
> that's true, I suppose, but it's still LCD-style, and doesn't actually

what's "LCD"?

> consider any of the implementation-specific stuff in _some_ of the
> Lisp implementations, which was my main point.

I don't understand this.  what "implementation-specific stuff" are you
talking about?

-- 
Sam Steingold (http://www.podval.org/~sds)
There are two kinds of egotists: 1) Those who admit it  2) The rest of us
From: Chris Double
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <wkitl05962.fsf@double.co.nz>
Sam Steingold <···@gnu.org> writes:

> > What implementation doesn't?  As far as I know, CMUCL does, CLISP
> > does, ACL, LispWorks, and CormanLisp all do.  Which don't?
> 
> GCL.  And CormanLisp appears to lack gray streams.

A preliminary implementation of gray streams for Corman Lisp:

http://www.double.co.nz/cl/gray-streams.zip

> 
> what's "LCD"?

Probably 'least common denominator'.

Chris.
-- 
http://www.double.co.nz/cl
From: David Bakhash
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <m37l1fvbcz.fsf@alum.mit.edu>
>>>>> "ss" == Sam Steingold <···@gnu.org> writes:

 >> This has nothing to do with Gray streams; it has to do with the
 >> socket

 ss> I wanted SOCKET to extend FUNDAMENTAL-STREAM - how else can you
 ss> make it a class _AND_ an stream?

I was coming from the camp where a socket is not necessarily a stream.
A server socket can accept a connection and return a (socket) stream;
a client can open up a (socket) stream to a server elsewhere.

Maybe I'm wrong here.  I'm not sure.  

 ss> _sockets_ (AKA 'active sockets') _are_ streams.  _socket-servers_
 ss> (AKA 'passive sockets') are _NOT_.

okay.  sockets (not streams) should certainly be classes.  Again, your 
``fix'' would accomplish a bit of what I would have changed; the rest
is just lacking features.  I hope you arn't offended.  net.lisp is
a fine offering.

 >> What implementation doesn't?  As far as I know, CMUCL does, CLISP
 >> does, ACL, LispWorks, and CormanLisp all do.  Which don't?

 ss> GCL.  And CormanLisp appears to lack gray streams.

yes.  sorry about that.  I thought it had them.

But to my knowledge, no one actually uses GCL, except for tinkering.  

 ss> what's "LCD"?

Least Common Denominator.

 >> consider any of the implementation-specific stuff in _some_ of the
 >> Lisp implementations, which was my main point.

 ss> I don't understand this.  what "implementation-specific stuff"
 ss> are you talking about?

`socket-control' (in ACL) is one example.  Someone also mentioned
recently that CMUCL also offers some advanced socket options, though I 
don't know details.

then, suppose you have an implementation which supports SSL (which do
exist).  that would easily be added in.  With your current net.lisp -- 
as is -- I don't see how that can be done effectively, without
changing the structure of your code (though your minor ``fix'' would
help)

It would be nice if an ssl-server-socket inherited from server-socket,
etc.  That's another point I was making.

But by not putting in that defclass --as minutely lacking as it was--
you've now exposed a part of the program that makes the addition of
code potentially break programs written in its current state (I'm
guessing).  Whereas, had you considered these things, you could have
exported symbols such that future improvements would be less likely to 
break code.

Utility-wise, I havn't used it, but by looking at it, it seems to do
the right thing, and given that it works with a bunch of
Lisp implementations, it's a fine thing to have.

dave
From: Rob Warnock
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <99js7f$3klkm$1@fido.engr.sgi.com>
David Bakhash  <·····@alum.mit.edu> wrote:
+---------------
| "ss" == Sam Steingold <···@gnu.org> writes:
|  ss> what's "LCD"?
| 
| Least Common Denominator.
+---------------

Annoying little nit:  For all x, y: LCD(x,y) ==> 1

I think you meant "GCD". (Or maybe "LCM", but probably not).


-Rob

-----
Rob Warnock, 31-2-510		····@sgi.com
SGI Network Engineering		<URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA
From: Kent M Pitman
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <sfwsnk25pms.fsf@world.std.com>
····@rigden.engr.sgi.com (Rob Warnock) writes:

> David Bakhash  <·····@alum.mit.edu> wrote:
> +---------------
> | "ss" == Sam Steingold <···@gnu.org> writes:
> |  ss> what's "LCD"?
> | 
> | Least Common Denominator.
> +---------------
> 
> Annoying little nit:  For all x, y: LCD(x,y) ==> 1
> 
> I think you meant "GCD". (Or maybe "LCM", but probably not).

Irregardless [sic] of this argument, it's an idiom.  One doesn't use
idioms based on reason.  One gets to either use them in their packaged
form or not.  You can, of course, try to create a new idiom.  And you
might more might not succeed.

But if I had to guess where the phrase comes from, it's trying to
express "excess conservatism".  GCD might suffice if one were going
after it analytically, but I think whoever coined the term "LCD" to
mean what it has come to mean adjectivally in "common" speech (for
various values of "common") either was confused about the math or
"could care less" [sic] about the math or else [most generous
interpretation] felt GCD to be overly optimistic and was seeking a way
of being more pejorative by saying "a solution that is even more
primitive than the intersection of the available options"...
From: David Bakhash
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <m33dc2p93b.fsf@alum.mit.edu>
>>>>> "kmp" == Kent M Pitman <Kent> writes:

 >> Annoying little nit: For all x, y: LCD(x,y) ==> 1
 >> 
 >> I think you meant "GCD". (Or maybe "LCM", but probably not).

Yeah -- I was speaking idiomatically, and didn't think about it in
literal mathematical terms, but yeah, if one did, I think GCD is more
along the lines.

 kmp> Irregardless [sic] of this argument, it's an idiom.  One doesn't
 kmp> use idioms based on reason.  One gets to either use them in
 kmp> their packaged form or not.  You can, of course, try to create a
 kmp> new idiom.  And you might more might not succeed.

I appreciate the literacy of this group, given that mine is very
limited.  I have certainly heard `least common denominator' used in
contexts such as this discussion many times, and never stopped to
think about it, since from the contexts those times I understood the
point being made.

Doing a simple google search shows articles like this:

http://www.virginia.edu/universityrelations/webguide5.html

titled:

  University of Virginia Web Standards and Guidelines

  PLAN FOR THE LEAST COMMON DENOMINATOR TECHNOLOGY

English is weird[i].

dave


Footnotes: 
[i]  `i' before `e' except after `c'.  Yeah, right.
From: Bob Riemenschneider
Subject: Least Common Denominator (was: Re: Free Linux Lisp and Sockets)
Date: 
Message-ID: <tpk85c2m1g.fsf_-_@coyote.csl.sri.com>
····@rigden.engr.sgi.com (Rob Warnock) writes:

> David Bakhash  <·····@alum.mit.edu> wrote:
> +---------------
> | "ss" == Sam Steingold <···@gnu.org> writes:
> |  ss> what's "LCD"?
> | 
> | Least Common Denominator.
> +---------------
> 
> Annoying little nit:  For all x, y: LCD(x,y) ==> 1
> 
> I think you meant "GCD". (Or maybe "LCM", but probably not).

Rob,

I think you're confusing "least common denominator" with "least common
divisor".  The least common denominator of two ratios, m1/n1 and
m2/n2, is the least common multiple of n1 and n2 "qua denominator".
This concept shows up, e.g., in the grade school algorithm for adding
"fractions": first find the least common denominator, then convert
each fraction so that it has that denominator, then add the converted
numerators retaining the common denominator, and finally "reduce to
lowest terms".  I tutored someone working on an elementary education
degree on this stuff some years ago and, if I recall correctly, the
motivation her text gave for dragging least common denominators in was
simply that, in adding, say, 1/6 and 1/12, you don't want
(unvisualizable) 72nds floating around when you can explain things in
terms of 12ths.

							-- rar
From: Barry Margolin
Subject: Re: Least Common Denominator (was: Re: Free Linux Lisp and Sockets)
Date: 
Message-ID: <iqQv6.122$U4.5855@burlma1-snr2>
In article <·················@coyote.csl.sri.com>,
Bob Riemenschneider  <···@coyote.csl.sri.com> wrote:
>····@rigden.engr.sgi.com (Rob Warnock) writes:
>
>> David Bakhash  <·····@alum.mit.edu> wrote:
>> +---------------
>> | "ss" == Sam Steingold <···@gnu.org> writes:
>> |  ss> what's "LCD"?
>> | 
>> | Least Common Denominator.
>> +---------------
>> 
>> Annoying little nit:  For all x, y: LCD(x,y) ==> 1
>> 
>> I think you meant "GCD". (Or maybe "LCM", but probably not).
>
>Rob,
>
>I think you're confusing "least common denominator" with "least common
>divisor".  The least common denominator of two ratios, m1/n1 and
>m2/n2, is the least common multiple of n1 and n2 "qua denominator".
>This concept shows up, e.g., in the grade school algorithm for adding
>"fractions": first find the least common denominator, then convert
>each fraction so that it has that denominator, then add the converted
>numerators retaining the common denominator, and finally "reduce to
>lowest terms".  I tutored someone working on an elementary education
>degree on this stuff some years ago and, if I recall correctly, the
>motivation her text gave for dragging least common denominators in was
>simply that, in adding, say, 1/6 and 1/12, you don't want
>(unvisualizable) 72nds floating around when you can explain things in
>terms of 12ths.

This is mildly interesting, but the original use of the term in this thread
was *not* in a mathematical context, it was referring to a piece of code
that uses CLOS.

In that context, "lowest common denominator" is frequently used to mean
"minimal set of features that are common to all implementations."  The code
in question avoided using advanced features that might not be available in
some implementations.

Ideally, a standard like ANSI CL defines a lowest common denominator, but
in the real world you sometimes have to accomodate implementations that are
not fully compliant with the standard, so the LCD may be somewhat lower
than that.

-- 
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: David Bakhash
Subject: Re: Least Common Denominator (was: Re: Free Linux Lisp and Sockets)
Date: 
Message-ID: <m3r8zkb2sg.fsf@alum.mit.edu>
>>>>> "bm" == Barry Margolin <······@genuity.net> writes:
 bm> This is mildly interesting, but the original use of the term in
 bm> this thread was *not* in a mathematical context, it was referring
 bm> to a piece of code that uses CLOS.

 bm> In that context, "lowest common denominator" is frequently used
 bm> to mean "minimal set of features that are common to all
              ^^^^^^^
 bm> implementations."  The code in question avoided using advanced
 bm> features that might not be available in some implementations.

I think it's actually the maximal set of features common to all -- not
the minimal.  This simple term has obviously been throwing people off, 
and even when we leave the mathematical terminology, as BM attempted,
it's not always obvious.

I think we all agree that the LCD of a set of implementations
comprises features that are common to all, and is the maximal set of
such features.

I think that assuming that what's in ANSI CL is not practical, as
people have pointed out, since several very useful (and widely used)
Lisp implementations do not conform fully.  However, I would rather
disclude an implementation on this account, or go through hell to use
a superior design based on ANSI CL than to sacrifice an API because of
the current lacking of an implementation.  It's better to provide
incentives for people to get their implementations up to spec than to
accept what's there and compromize.  That's the point of having a
standard, in my opinion.

dave
From: Bob Riemenschneider
Subject: Re: Least Common Denominator (was: Re: Free Linux Lisp and Sockets)
Date: 
Message-ID: <tphf0e3n85.fsf@coyote.csl.sri.com>
David Bakhash <·····@alum.mit.edu> writes:

> >>>>> "bm" == Barry Margolin <······@genuity.net> writes:
>  bm> In that context, "lowest common denominator" is frequently used
>  bm> to mean "minimal set of features that are common to all
>  bm> implementations."  
> 
> I think it's actually the maximal set of features common to all -- not
> the minimal.  ...

Actually, you and barmar are both right: it's both the minimum set
among sets of features that contain all common features -- thus a
minimal set of features each of which is common to all implementations
(which is how I read barmar's remark) -- and the maximum set among
sets of features that contain only common features.  

I thought explaining the literal usage would make the metaphorical
usage clear, but maybe not. :-)

						-- rar
From: Chris Double
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <wkr8zo6pbn.fsf@double.co.nz>
David Bakhash <·····@alum.mit.edu> writes:

> > first, not all supported implementations implement `close' as a gf.
> > second, a `socket-server' is not a stream, and IMO, `close' should be
> > used only by the streams.
> 
> What implementation doesn't?  As far as I know, CMUCL does, CLISP
> does, ACL, LispWorks, and CormanLisp all do.  Which don't?

Corman Lisp doesn't unfortunately. Close is a normal function. I had
to do some hoop jumping to get close to recognise socket streams in my
sockets package.

I've done a gray streams implementation at my web site for Corman Lisp
that provides a generic though.

Chris.
-- 
http://www.double.co.nz/cl
From: Duane Rettig
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <4bsqroq5y.fsf@beta.franz.com>
Chris Double <·····@double.co.nz> writes:

> David Bakhash <·····@alum.mit.edu> writes:
> 
> > > first, not all supported implementations implement `close' as a gf.
> > > second, a `socket-server' is not a stream, and IMO, `close' should be
> > > used only by the streams.
> > 
> > What implementation doesn't?  As far as I know, CMUCL does, CLISP
> > does, ACL, LispWorks, and CormanLisp all do.  Which don't?
> 
> Corman Lisp doesn't unfortunately. Close is a normal function. I had
> to do some hoop jumping to get close to recognise socket streams in my
> sockets package.
> 
> I've done a gray streams implementation at my web site for Corman Lisp
> that provides a generic though.

I think that it was an unfortunate mistake that the Gray Proposal
specified CLOSE to be generic, rather than following its own cadence
and adding a STREAM-CLOSE gf along with all of the other STREAM-* gfs
that it specified.

When we were working out the new simple-streams design last year that
Allegro CL now uses, I tried hard to un-generify CLOSE, but found too
many problems with legacy Gray streams usage.  So we stuck with the
generic version, whose simple-stream method simply calls device-close
(the simple-stream close implementation).

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: David Bakhash
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <m3g0g4v6ro.fsf@alum.mit.edu>
>>>>> "cd" == Chris Double <·····@double.co.nz> writes:
 cd> Corman Lisp doesn't unfortunately. Close is a normal function. I
 cd> had to do some hoop jumping to get close to recognise socket
 cd> streams in my sockets package.

I thought I'd read that it supported the Gray streams spec, and
assumed that close was defined as a gf.  thanks for the correction.

dave
From: Tim Bradshaw
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <nkjbsqo28o9.fsf@tfeb.org>
David Bakhash <·····@alum.mit.edu> writes:
> 
> What implementation doesn't?  As far as I know, CMUCL does, CLISP
> does, ACL, LispWorks, and CormanLisp all do.  Which don't?
> 

CMUCL does not (18c, 2000-11-27 on solaris).

--tim
From: Raymond Toy
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <4nofuo8vck.fsf@rtp.ericsson.se>
>>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:

    Tim> David Bakhash <·····@alum.mit.edu> writes:
    >> 
    >> What implementation doesn't?  As far as I know, CMUCL does, CLISP
    >> does, ACL, LispWorks, and CormanLisp all do.  Which don't?
    >> 

    Tim> CMUCL does not (18c, 2000-11-27 on solaris).

I think you need to load the gray-streams-library to get close as a
generic function.

(You may also want to get a new binary since the original one forgot
to include the gray-streams-library.  Or you can easily compile up the
library if you have the two gray-streams files.)

Ray
From: Christophe Rhodes
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <sqwv9cvcbc.fsf@lambda.jesus.cam.ac.uk>
Tim Bradshaw <···@tfeb.org> writes:

> David Bakhash <·····@alum.mit.edu> writes:
> > 
> > What implementation doesn't?  As far as I know, CMUCL does, CLISP
> > does, ACL, LispWorks, and CormanLisp all do.  Which don't?
> 
> CMUCL does not (18c, 2000-11-27 on solaris).

Not by default, anyway, though there is a gray-streams-library
distributed with it.

Irritatingly, there appears not to be a way of testing whether it's
loaded (apart from the slightly dubious 
(ignore-errors (ensure-generic-function 'close))
...)

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 524 842
(FORMAT T "(·@{~w ········@{~w~^ ~})" 'FORMAT T "(·@{~w ········@{~w~^ ~})")
From: Kent M Pitman
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <sfwae687fu9.fsf@world.std.com>
Christophe Rhodes <·····@cam.ac.uk> writes:

> Tim Bradshaw <···@tfeb.org> writes:
> 
> > David Bakhash <·····@alum.mit.edu> writes:
> > > 
> > > What implementation doesn't?  As far as I know, CMUCL does, CLISP
> > > does, ACL, LispWorks, and CormanLisp all do.  Which don't?
> > 
> > CMUCL does not (18c, 2000-11-27 on solaris).
> 
> Not by default, anyway, though there is a gray-streams-library
> distributed with it.
> 
> Irritatingly, there appears not to be a way of testing whether it's
> loaded (apart from the slightly dubious 
> (ignore-errors (ensure-generic-function 'close))
> ...)

Seems like you could test for (FIND-CLASS 'FUNDAMENTAL-STREAM) [possibly 
dealing with package foothold issues; does everyone put this stuff in the
same package?] or something more distinctive to gray streams than just a
generic CLOSE.  There are a lot of reasons why CLOSE might be generic.

Maybe we could encourage the vendors in the future to include something on
*FEATURES* for any popular facilities like this that they support.
From: Ole Rohne
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <ebwy9tssk38.fsf@atlas008.cern.ch>
Tim Bradshaw <···@tfeb.org> writes:

> CMUCL does not (18c, 2000-11-27 on solaris).

[... implement CLOSE as a gf]

It does once the gray-streams-library is loaded. You'll find it in the
updated 'extra' file at cons.org.

Starting /user/mrohne/bin/lisp ...
; Loading #p"/user/mrohne/.cmucl-init".
CMU Common Lisp 18c, Built 2000-11-27, running on suntrt2
Send questions and bug reports to your local CMU CL maintainer, or to ··········@cons.org. and ·········@cons.org. respectively.
Loaded subsystems:
    Python 1.0, target SPARCstation/Solaris 2
    CLOS based on PCL version:  September 16 92 PCL (f)
    CLX X Library MIT R5.02
    Motif toolkit and graphical debugger 1.0
* 
* (describe #'close)
#<Standard-Generic-Function COMMON-LISP::PCL-CLOSE (3) {282515B9}> is function.
#<Standard-Generic-Function COMMON-LISP::PCL-CLOSE (3) {282515B9}> is a generic function.
Its arguments are:
  (STREAM &KEY ABORT)
Its methods are:
From: Kent M Pitman
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <sfw3dc4kr72.fsf@world.std.com>
Sam Steingold <···@gnu.org> writes:

> > Can I define methods on it, in the general case?  NO.  Why?  because
> > you can't use a deftype as a method specializer.  So that makes your
> > code annoying for use with CLOS.
> 
> these was a discussion on CLOSifying net.lisp on the clocc-list in May
> 2000.  There appeared to be little support for this.
> Franz declared they they are moving away from the Gray streams, so
> apparently sockets should not use them "for future portability".

What did they say they were moving toward?  Hopefully something they can
(a) motivate properly and (b) lobby for industry-wide support for.  It'd be a
darned shame if what little vestige of portable support there is for streams
gets washed away in this way..
From: Pierre R. Mai
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <87wv9gav25.fsf@orion.bln.pmsf.de>
Kent M Pitman <······@world.std.com> writes:

> Sam Steingold <···@gnu.org> writes:
> 
> > > Can I define methods on it, in the general case?  NO.  Why?  because
> > > you can't use a deftype as a method specializer.  So that makes your
> > > code annoying for use with CLOS.
> > 
> > these was a discussion on CLOSifying net.lisp on the clocc-list in May
> > 2000.  There appeared to be little support for this.
> > Franz declared they they are moving away from the Gray streams, so
> > apparently sockets should not use them "for future portability".
> 
> What did they say they were moving toward?  Hopefully something they can
> (a) motivate properly and (b) lobby for industry-wide support for.  It'd be a
> darned shame if what little vestige of portable support there is for streams
> gets washed away in this way..

If things haven't changed a lot since last April, then the thing they
are moving toward is "The New Allegro CL Streams Design", which had
been announced in posting <················@beta.franz.com> to
comp.lang.lisp on 2000-04-18, under the subject "Call for Comments:
The New Allegro CL Streams Design".  It seems to me they were fairly
clear that they wanted to do both (a) and (b), and at the time there
was no negative public reaction to their plans, AFAIK.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Duane Rettig
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <4hf0joqww.fsf@beta.franz.com>
"Pierre R. Mai" <····@acm.org> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > Sam Steingold <···@gnu.org> writes:
> > 
> > > Franz declared they they are moving away from the Gray streams, so
> > > apparently sockets should not use them "for future portability".
> > 
> > What did they say they were moving toward?  Hopefully something they can
> > (a) motivate properly and (b) lobby for industry-wide support for.  It'd be a
> > darned shame if what little vestige of portable support there is for streams
> > gets washed away in this way..
> 
> If things haven't changed a lot since last April, then the thing they
> are moving toward is "The New Allegro CL Streams Design", which had
> been announced in posting <················@beta.franz.com> to
> comp.lang.lisp on 2000-04-18, under the subject "Call for Comments:
> The New Allegro CL Streams Design".  It seems to me they were fairly
> clear that they wanted to do both (a) and (b), and at the time there
> was no negative public reaction to their plans, AFAIK.

This entire paragraph is correct, as are the references to the
current documentation in a couple of other posts on this thread.  As
for reactions, we did get some very good comments, and one person
asked about potentially porting simple-streams to CMUCL, though I am
not sure if there was any movement in that direction.  I have
appended a message below which is an answer I sent back to that
person, explaining our direction at that time; I think that it
still accurately reflects our position.

I won't be able to attend our Developer Symposium Sunday and Monday,
but Charley Cox will be there and has an excellent presentation on
Internationalization (Sunday the 25th, from 11:00-12:30).  It goes
into issues about international character sets and touches on the
simple-streams design slightly.  I would recommend it for anyone who
is interested in i18n and/or simple-streams, and I'm sure Charley
would be happy to discuss design issues about either after his talk.


-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)


Here is the answer I sent to the person who asked about implementing
simple-streams in another lisp:

=====
From: Duane Rettig <duane>


--------
    Date:  07 Aug 2000 22:04:51 +0300
    From:  <name-removed-for-privacy>

    | Duane Rettig <·····@franz.com> writes:
    
    | <old-url>/simple-stream.htm
    | 
    | This document is slightly out-of-date; changes have been made, both to the
    | design and documentation, based on user inputs form a previous posting on
    ...
    | beta test very shortly).  The kinds of changes that are not in the above
    | documentation include the addition of stream encapsulation and clarification
    | of some of the concepts.  But the above document should be understandable
    | and should give you a feel for the direction we are headed.
    
    Hm.  Let's say I'd like to /implement/ simple stream system and I
    (try to) do that based on the document on WWW that you say is
    slightly out-of-date.  In your opinion, will I lose?

The document is designed for other implementors to win.  I am not sure
what you mean by "lose", so I'll enumerate some of the possible
interpretations, and try to answer each one.  I must assume that you
have read the document already (possibly from the first time I posted),
otherwise I will ask you to read the document first, and then decide
for yourself whether the design is a portable one.

 1. If I implement it in CL implementation X, will it be incompatible with
Allegro CL's implementation?

  The intention is that you will have mostly compatible code.  During times
when we transitioned from device-level programming in Common Graphics, which
actually had a very old implemenation of simple-streams, to the newer version,
and then even further into the tweaks that we made to allow encapsulations,
the device-level programming for things like device-open and
device-read/device-write were very understandable by the users, and resulted
in very little changes required.  Thus, I assume that a reasonably implemented
simple-streams version in another lisp would also enjoy the same portability.
Of course, as a caveat, the document does not describe a formally accepted spec,
so it is not possible to be 100% compatible.

 2. If I implement it in CL implementation X, will it be slower than
molassis?

 Hopefully not, but I can't precdict how good your implementation will
be.  I would have to admit being a competitor in this particular area,
and so I will predict that Allegro CL will beat all comers ... :-)

 3. If I implement my own simple-streams in Allegro CL, will I have to work
hard to get my code to work once Allegro CL 6.0 comes out?

 Probably not too hard,  based on the answer to #1, but I would recommend
that you wait anyway for 6.0.

 4. If I implement simple-streams in CL implementation X according to the
above document, will I have to re-implement it in order to stay with the
6.0 version?

 Yes, but not by much.  Our original design has changed very little, but even
now it is changing; I expect some slight tweaks even between the 6.0 beta
implementation and 6.0 final, as we find stream concepts that don't fit
perfectly into the current model.

And now for my question to you: why do you ask?  Are you interested in
implementing simple-streams in another lisp, or asking another vendor to
do so?  (not a Bad Thing, by the way; in fact I'd love to see that happen)

Duane
From: Pierre R. Mai
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <87k85gauoa.fsf@orion.bln.pmsf.de>
"Pierre R. Mai" <····@acm.org> writes:

> If things haven't changed a lot since last April, then the thing they
> are moving toward is "The New Allegro CL Streams Design", which had
> been announced in posting <················@beta.franz.com> to
> comp.lang.lisp on 2000-04-18, under the subject "Call for Comments:
> The New Allegro CL Streams Design".  It seems to me they were fairly
> clear that they wanted to do both (a) and (b), and at the time there
> was no negative public reaction to their plans, AFAIK.

The documentation for the current implementation of their proposal, as
contained in ACL 6.0, can be viewed at

http://www.franz.com/support/documentation/6.0/doc/streams.htm

This document gives also the rationale for their move, and the amount
of gray-stream backward compatability they provide.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Chris Double
Subject: Re: Free Linux Lisp and Sockets
Date: 
Message-ID: <wkr8zo59bt.fsf@double.co.nz>
Kent M Pitman <······@world.std.com> writes:

> What did they say they were moving toward?  Hopefully something they
> can (a) motivate properly and (b) lobby for industry-wide support
> for.  It'd be a darned shame if what little vestige of portable
> support there is for streams gets washed away in this way..

See:

http://www.franz.com/support/documentation/6.0/doc/streams.htm

They posted a request for comments on the proposal some time ago.

Chris.
-- 
http://www.double.co.nz/cl