From: Thomas Fischbacher Subject: Proposal: Standard network interface for various CL's Date: Message-ID: <oa1bu554f2h.fsf@hphalle0a.informatik.tu-muenchen.de>
Common LISP is a comparatively large and rather complicated standard,
mainly because it's the result of an effort to re-unite a large
variety of different LISP dialects. Still, there are many topics which
are not covered by CL. Networking is one of them.
Well, one might say, then don't use LISP for network programming but a
"network language" like Java. The problem is, however, that there is
no widely-known language around supporting network programming as well
as functional concepts. A lot of people consider Java a very good
network language, but since it is entirely non-functional, it's just
as limited as C, and therefore definitely is not the language of
choice for more abstract problems that require the full functional
arsenal. (currying, closures, etc.) Most people will consider
functional languages on top of Java (e.g. Pizza, Kawa) too clumsy for
bigger projects, so what to do?
Most of the quick & dirty network applications one needs from time to
time are written in perl, since this is a quick & dirty hacking
language which doesn't require all the overhead that's usually
neccessary in so many object-oriented programming languages, and you
can even solve minor problems via 'perl -e' from the shell
prompt. When it comes to doing more sophisticated things, however,
perl is often not very well-suited. (I'd *really* like to know how many
perl programmers have mastered the techniques neccessary to handle
arrays of arrays... more than three? :-) )
Now imagine a flexible network interface with which you can work from
the read-eval-print loop, a network interface for LISP.
The question how to make LISP use IP sockets is not new; some
packages, like CLX (not exclusively), require minimal network support,
therefore people started hacking special-purpose C code into their
LISPs to solve that problem. The wheel was re-invented over and over
again here. As a result, we now have a multitude of patches and hacks
for a lot of different LISPs that provide network functions for
special packages. It is absolutely not uncommon to have two or three
different kinds of crippled network interfaces within the same CL at
the same time to support different packages. Making it work is another
issue; there is no common way how to emplant C code into existing
LISPs. If you are unlucky (I don't know about you, but I usually am),
even one single LISP might use multiple different and incompatible
techniques on different platforms. Take for example GCL, where faslink
is not supported for ELF. Or have a look at your Allegro manual.
(Was it "dclfn"?)
LISP is a great language for writing re-usable code, but somehow,
re-inventing something which has been implemented before is also very
very tempting. (Is this the "devilish" side of LISP?) In the case of
networking, this is even more counter-productive than usual. Therefore
I regard it as neccessary that we sit down and work out one "standard"
TCP/IP network interface. Now. What do you think?
P.S.: I've recently hacked up a small general-purpose network
interface for GCL(*) and got very promising results, though it wasn't
designed especially with other LISPs or something different from Unix
in mind. But I think I have a pretty good idea how such a package
should look like.
(*) Say what you want. I like this hackish LISP for that kind of
experiments. :-)
--
regards,
Thomas Fischbacher - ··@another.gun.de
········@informatik.tu-muenchen.deFrom: Marco Antoniotti Subject: Re: Proposal: Standard network interface for various CL's Date: Message-ID: <scfena15hbh.fsf@infiniti.PATH.Berkeley.EDU>
In article <···············@hphalle0a.informatik.tu-muenchen.de> Thomas Fischbacher <········@hphalle0a.informatik.tu-muenchen.de> writes: From: Thomas Fischbacher <········@hphalle0a.informatik.tu-muenchen.de> Newsgroups: comp.lang.lisp Date: 17 Jun 1997 13:57:42 +0200 Organization: Inst. fuer Informatik, TU Muenchen, Germany Lines: 69 Distribution: world X-Newsreader: Gnus v5.2.25/XEmacs 19.14 Common LISP is a comparatively large and rather complicated standard, mainly because it's the result of an effort to re-unite a large variety of different LISP dialects. Still, there are many topics which are not covered by CL. Networking is one of them. ... Now imagine a flexible network interface with which you can work from the read-eval-print loop, a network interface for LISP. ... LISP is a great language for writing re-usable code, but somehow, re-inventing something which has been implemented before is also very very tempting. (Is this the "devilish" side of LISP?) In the case of networking, this is even more counter-productive than usual. Therefore I regard it as neccessary that we sit down and work out one "standard" TCP/IP network interface. Now. What do you think? P.S.: I've recently hacked up a small general-purpose network interface for GCL(*) and got very promising results, though it wasn't designed especially with other LISPs or something different from Unix in mind. But I think I have a pretty good idea how such a package should look like. (*) Say what you want. I like this hackish LISP for that kind of experiments. :-) I agree. But the best thing to do is toput forward a document that describes such an interface and that does not preclude its implementation in other CL implementations. Moreover, it is not just a matter of describing the interface, it is also a matter of providing a good and expandable package structure which does not conflict with other tools "out there". Cheers -- Marco Antoniotti ============================================================================== California Path Program - UCB Richmond Field Station tel. +1 - 510 - 231 9472
From: Thomas Fischbacher Subject: Re: Proposal: Standard network interface for various CL's Date: Message-ID: <oa1oh8vgmhl.fsf@hphalle4a.informatik.tu-muenchen.de>
·······@infiniti.PATH.Berkeley.EDU (Marco Antoniotti) writes:
> I agree. But the best thing to do is toput forward a document that
> describes such an interface and that does not preclude its
> implementation in other CL implementations.
I'd suggest to do it in a way very similar to the network interface of
scsh, since (1) this is an existing, working package which seems to
have virtually all the functionality one needs (with very few exceptions,
however.), (2) it's sufficiently low-level. Of course, it would be
very nice to have network connections appear as streams within
LISP. But there are some important IP details which can't be mapped
well onto streams. Think of UDP Datagrams or OOB data, for example.
What do you say?
--
regards,
Thomas Fischbacher - ··@another.gun.de
········@informatik.tu-muenchen.deFrom: Rainer Joswig Subject: Re: Proposal: Standard network interface for various CL's Date: Message-ID: <joswig-ya023180001706971743430001@news.lavielle.com>
In article <···············@hphalle0a.informatik.tu-muenchen.de>, Thomas Fischbacher <········@hphalle0a.informatik.tu-muenchen.de> wrote: > Common LISP is a comparatively large and rather complicated standard, > mainly because it's the result of an effort to re-unite a large > variety of different LISP dialects. Still, there are many topics which > are not covered by CL. Networking is one of them. True. CL-HTTP runs (or did run) in LCL, LW, SCL, MCL, ACL, ... It may even run (somehow) under ACL/PC and CMU CL. So it seems that there is a kind of substrate that makes it possible to write servers and clients on a number of platforms (and their TCP/IP support). Looks like a good starting point. ***And*** it is free (that is: not vendor controlled, which is really good if you look what happened to the CLIM "effort"). How about a state of the art, *portable* and *public* library for some basic protocols (client and/or server): DNS, SMTP, NNTP, POP3, IMAP4, SNMP, ... The LispOS guys sure would like to have that, too. -- http://www.lavielle.com/~joswig/
From: Howard R. Stearns Subject: Re: Proposal: Standard network interface for various CL's Date: Message-ID: <33A7E636.1CFBAE39@elwoodcorp.com>
Rainer Joswig wrote: > > In article <···············@hphalle0a.informatik.tu-muenchen.de>, Thomas > Fischbacher <········@hphalle0a.informatik.tu-muenchen.de> wrote: > > > Common LISP is a comparatively large and rather complicated standard, > > mainly because it's the result of an effort to re-unite a large > > variety of different LISP dialects. Still, there are many topics which > > are not covered by CL. Networking is one of them. > > True. > > CL-HTTP runs (or did run) in LCL, LW, SCL, MCL, ACL, ... > It may even run (somehow) under ACL/PC and CMU CL. > So it seems that there is a kind of substrate that > makes it possible to write servers and clients > on a number of platforms (and their TCP/IP support). > Looks like a good starting point. ***And*** > it is free (that is: not vendor controlled, which > is really good if you look what happened to the > CLIM "effort"). > > How about a state of the art, *portable* and *public* library for > some basic protocols (client and/or server): DNS, SMTP, > NNTP, POP3, IMAP4, SNMP, ... The LispOS guys sure would > like to have that, too. I believe that ILU also implements some network protocols in a portable way. See ftp://ftp.cs.cmu.edu/user/ai/lang/lisp/code/ilu/0.html Some (naive?) opinions on how such a protocol MIGHT be structured: 1. Agree that a general foreign function interface is a good and necessary thing, but that standardizing one is outside the scope of the network interface. However, some FFI use will, of course, be necessary, and some "not quite standardized" subprotocol will probably be necessary. It should probably be compatible with that used by CL-HTTP and ILU. It is likely that use of this subprotocol will still require a lot of readtime conditionalization. Anyway, the idea is just to provide enough of a veneer to allow the body of a reference implementation of the main networking code to be written. This FFI code would NOT be seen by Lisp programmers USING the network code. 2. Build on CLOS streams. Use the "Stream-definition-by-user" protocol by David Gray, as implemented in CLIM. Extend this to support the additional classes. 3. Solve the OPEN problem. That is, provide a way for OPEN to make use of user defined streams. (I have a sample implementation of this that uses a method keyed off of pathname, truename, direction, external-format, and element-type to come up with the stream class. It can be specialized by users, and has a default method that uses the last three arguments to come up with a stream class.) 4. (Extra credit) Create a "pathname-definition-by-user" protocol. This allows programmers to define pathnames that refer to networked locations and provide methods specialized to make normal pathname operations work with the newly defined protocols. I have no idea if CL-HTTP or ILU's handling is compatible with these ideas. I'm hoping that it would be possible to specify a network stream protocol (2, 3, & 4) that could be implemented: A. by vendors directly B. as a portable reference implementation, using (1) C. as a "using-cl-http" implementation D. as a "using-ilu" implementation Ideally, B, C, and C would all be the same thing, but that remains to be seen. Eventually, if A existed on each platform, then CL-HTTP and ILU might use this protocol for their internals rather than the other way around. Anyway, its just a thought.