I has become apparent to me that though the APIs from various Lisp
implementations are similar, they are significantly different enough to
cause headaches and wasted effort. Many other languages benefit from having
one standardizing vendor (and library interface) as in the case of Perl,
Python and Java. Common Lisp can stand to have multiple implementations but
would benefit greatly from a standardized API. I am a relative newbie here
but my suggestion is to put the technical merits of who has the best
application API aside and have the Lisp community produce Franz ACL
compatibility packages for
LispWorks,
Corman Lisp,
CMUCL,
MCL
for the following packages,
FFI,
Sockets and SSL Sockets,
Multiprocessing,
ODBC,
Sundry ACL enhancements,
and maybe even Common Windows.
Make Franz the defacto standard. Their API is good enough. Applications
could then be written and be available for a broader number of platforms and
Common Lisps.
Wade
"Wade Humeniuk" <········@cadvision.com> writes:
> Multiprocessing,
I don't want to comment on the political issues here, or even most of
thre technical ones. But I don't think anyone has an MP framework
which should be standardised. All the CL MP systems I've seen
gleefully expose thinge like WITHOUT-PREEMPTION (hideous on a
multiprocessor) and allow totally general code to run to decide
whether a thread is runnable (hideous on top of any OS threading
system I think).
--tim
>>>>> "tim" == Tim Bradshaw <···@tfeb.org> writes:
tim> "Wade Humeniuk" <········@cadvision.com> writes:
>> Multiprocessing,
tim> I don't want to comment on the political issues here, or even
tim> most of thre technical ones.
yes. too many issues. Which vendor is going to say "okay. let's use
the ACL interface, even though we think ours is better." ???
Personally, I like ACL's socket interface, LispWorks's SQL and Corba
interfaces, and don't even want to think about FFIs.
Picking a single vendor's way of doing it is a half-assed way of
standardizing anything. You can standardize it yourself by picking
a vendor you're comfortable with, and using their Lisp. There are
several good ones out there.
It would make much more sense if you wrote to a vendor and said, "I
really like the way this other vendor implements foo..." and see what
they have to say.
dave
"Wade Humeniuk" <········@cadvision.com> writes:
> but my suggestion is to put the technical merits of who has the best
> application API aside and have the Lisp community produce Franz ACL
> compatibility packages for
The longer I read this newsgroup the less tolerant I get of
implications that there is a vast pool of free-for-the-taking
development resource out there that only needs a suggestion from some
random Usenet poster before it will rally round a single project and
dispatch it in two months flat.
So if "have the Lisp community produce ..." is actually shorthand for
"I am fully cognizant of the saying `He who writes the code controls
the project direction' and fully intend to do this all myself, but I
would be grateful for any help offered" then I apologise for jumping
down your throat. We've had (what seems like) an awful lot of "I
want" lately, and the second-best advice I could give to anyone
wanting to start a new community project is to choose his words
carefully when posting to c.l.l.
[ Have you looked at the CLOCC PORT library? ]
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
"Daniel Barlow" <···@telent.net> wrote in message
···················@noetbook.telent.net...
> "Wade Humeniuk" <········@cadvision.com> writes:
>
> > but my suggestion is to put the technical merits of who has the best
> > application API aside and have the Lisp community produce Franz ACL
> > compatibility packages for
>
> The longer I read this newsgroup the less tolerant I get of
> implications that there is a vast pool of free-for-the-taking
> development resource out there that only needs a suggestion from some
> random Usenet poster before it will rally round a single project and
> dispatch it in two months flat.
There is NOT a vast pool of free-for-the-taking resources. That is the
point. There was a pervious thread about an FFI to renderman, if that work
was applicable to most of the major Lisps it would reduce the overall effort
in the long run. But that usually does not happen because everyone is short
on time and cannot be bothered to deal with compatibility issues. The Lisp
vendors got together to produce the ANSI standard, why not an API? There
have been discussions in that direction before.
I do not give a damn about who controls what and I have no intention of
doing it or have the expertise to accomplish it within a useful timeframe.
Cooperation would be necessary.
I personally have picked a single vendor (Xanalys), and put my money where
my mouth is. When I produced something, I wanted to move it to the Mac, but
you know the story. Money, Money, Money.
As a developer who is basically on their own, it feels like I am swinging in
the wind.
And no I have not looked at CLOCC lately, the last time it looked there was
not anything I needed.
Wade
"Wade Humeniuk" <········@cadvision.com> writes:
> "Daniel Barlow" <···@telent.net> wrote in message
> ···················@noetbook.telent.net...
> > "Wade Humeniuk" <········@cadvision.com> writes:
> >
> > > but my suggestion is to put the technical merits of who has the best
> > > application API aside and have the Lisp community produce Franz ACL
> > > compatibility packages for
> >
> > The longer I read this newsgroup the less tolerant I get of
> > implications that there is a vast pool of free-for-the-taking
> > development resource out there that only needs a suggestion from some
> > random Usenet poster before it will rally round a single project and
> > dispatch it in two months flat.
>
> [ snip ]
>
> I do not give a damn about who controls what and I have no intention of
> doing it or have the expertise to accomplish it within a useful timeframe.
> Cooperation would be necessary.
So, co�peration is necessary, but you're not willing to help? Or is
that not what you're saying?
> I personally have picked a single vendor (Xanalys), and put my money where
> my mouth is. When I produced something, I wanted to move it to the Mac, but
> you know the story. Money, Money, Money.
So, you want other people to work for free to help you make money? Or
is that not what you're saying?
> As a developer who is basically on their own, it feels like I am swinging in
> the wind.
Has it occurred to you to try to convince other developers to help? To
do some work and show other people at least a proof-of-concept, saying
"here is how this makes both your and my life easier; care to join
in?"
> And no I have not looked at CLOCC lately, the last time it looked there was
> not anything I needed.
Well, that's as may be. Did you volunteer to help? Contribute
something that you consider useful, criticize constructively, submit
patches or bug reports?
I'm sorry, but from a human psychology point of view, saying "I think
it should be this way; now go and make it so!" is unlikely to cause
much to happen, except for a certain amount of righteous indignation.
Please consider joining the lisp community.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
>
> I'm sorry, but from a human psychology point of view, saying "I think
> it should be this way; now go and make it so!" is unlikely to cause
> much to happen, except for a certain amount of righteous indignation.
>
You are right. It is time for me to face the reality of the situation.
This is probably the only programming language that has five or more
completely different APIs for sockets. That is the reality.
Wade
"Wade Humeniuk" <········@cadvision.com> writes:
> You are right. It is time for me to face the reality of the situation.
> This is probably the only programming language that has five or more
> completely different APIs for sockets. That is the reality.
There are "five or more" completely different interfaces to sockets in
C, Smalltalk, APL, and just about every other language out there which
has more that one implemenation or runs on more than one operating
system. I don't think Common Lisp any worse off than anybody else in
this regard.
Carl Shapiro wrote:
> "Wade Humeniuk" <········@cadvision.com> writes:
>
>> You are right. It is time for me to face the reality of the situation.
>> This is probably the only programming language that has five or more
>> completely different APIs for sockets. That is the reality.
>
> There are "five or more" completely different interfaces to sockets in
> C, Smalltalk, APL, and just about every other language out there which
> has more that one implemenation or runs on more than one operating
> system. I don't think Common Lisp any worse off than anybody else in
> this regard.
But saying "The others do so too" doesn't help here anything.
We have _now_ the chance to do a common socket API including support for
SSL and I think this would be a good thing. I don't see the benefit of such
a diversity in API here....
As I said in the other thread - I'm over to implement a SSL binding for
LispWorks - the offering is that we can do it this times together!
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> Carl Shapiro wrote:
>
> > "Wade Humeniuk" <········@cadvision.com> writes:
> >
> >> You are right. It is time for me to face the reality of the situation.
> >> This is probably the only programming language that has five or more
> >> completely different APIs for sockets. That is the reality.
> >
> > There are "five or more" completely different interfaces to sockets in
> > C, Smalltalk, APL, and just about every other language out there which
> > has more that one implemenation or runs on more than one operating
> > system. I don't think Common Lisp any worse off than anybody else in
> > this regard.
>
> But saying "The others do so too" doesn't help here anything.
?
But it does to dispel the crazy myth that Common Lisp is the only
language out there with n + 1 interfaces to some random operating
system's socket facility.
Carl Shapiro wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> Carl Shapiro wrote:
>>
>> > "Wade Humeniuk" <········@cadvision.com> writes:
>> >
>> >> You are right. It is time for me to face the reality of the
>> >> situation. This is probably the only programming language that has
>> >> five or more
>> >> completely different APIs for sockets. That is the reality.
>> >
>> > There are "five or more" completely different interfaces to sockets in
>> > C, Smalltalk, APL, and just about every other language out there which
>> > has more that one implemenation or runs on more than one operating
>> > system. I don't think Common Lisp any worse off than anybody else in
>> > this regard.
>>
>> But saying "The others do so too" doesn't help here anything.
>
> ?
>
> But it does to dispel the crazy myth that Common Lisp is the only
> language out there with n + 1 interfaces to some random operating
> system's socket facility.
Maybe I've not read all but I cannot remember someone saying that.
I think the fact that there are different APIs for the same thing is worse
enough. I remember nobody saying "Hey Common Lisp is drek 'cause it has
several different socket APIs while all other languages have only one!"
I know this question is a frequently asked one - but since it is asked so
often this may mean that the problem is not solved yet.
What I find so sad is that there are people that sit down and _try_ to do a
common API and then if it is done the people come and complain on the
implementation.
This is why I say now - "Let's discuss the technical side of the problem -
lets find solutions!" not things like "why is this problem here" or "is
Common Lisp a worse language because it has this problem now."
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> [Carl Shapiro]
> > But it does to dispel the crazy myth that Common Lisp is the only
> > language out there with n + 1 interfaces to some random operating
> > system's socket facility.
>
> Maybe I've not read all but I cannot remember someone saying that.
Well:
This is probably the only programming language that has five or more
completely different APIs for sockets. That is the reality.
So I guess you haven't read all the articles.
--tim
"Tim Bradshaw" <···@tfeb.org> wrote in message
····················@tfeb.org...
> Jochen Schmidt <···@dataheaven.de> writes:
>
> > [Carl Shapiro]
> > > But it does to dispel the crazy myth that Common Lisp is the only
> > > language out there with n + 1 interfaces to some random operating
> > > system's socket facility.
> >
> > Maybe I've not read all but I cannot remember someone saying that.
>
> Well:
>
> This is probably the only programming language that has five or more
> completely different APIs for sockets. That is the reality.
>
> So I guess you haven't read all the articles.
You are right Tim, I thought that CL was about the only language to have
many interfaces to sockets. The majority of my experience is with C/C++ and
when it comes to C interfaces there I have only really used one, the BSD
sockets interface. Whether is was Windows, OS2, Unix, embedded systems,
they all had the same (approximately) interface.
Wade
"Wade Humeniuk" <········@cadvision.com> writes:
> You are right Tim, I thought that CL was about the only language to have
> many interfaces to sockets. The majority of my experience is with C/C++ and
> when it comes to C interfaces there I have only really used one, the BSD
> sockets interface. Whether is was Windows, OS2, Unix, embedded systems,
> they all had the same (approximately) interface.
This is one of C's great virtues, what I was trying to explain was why
it happens.
This is getting pretty offtopic, but I think we often forget that CL
has an unusually high number of implementations. From where I'm
sitting I have access to four near-ANSI implementations intended for
serious use, three of which are commercial implementations of very
good quality, and the fourth is CMUCL which is not commercial but also
pretty serious. On my machines I have at home I have three near-ANSi
implementations (one commercial) and gcl on solaris, and two (both
commercial) on Windows, as well as genera, which is also near-ANSI.
And I'm not trying too hard - I don't have CLISp on windows for
instance. For comparison, I've never used a machine with more than two
C compilers.
Given this, and given that Lisp implementations are not typically
bound into the OS in the way that C implementations are (Genera being
a notable exception, of course), I think it's fairly easy to see why
there are multiple APIs to things and why unification is not easy.
That doesn't mean unification is not desirable - I think it is, so
long as it's unification around a standard which is acceptable (see
Duane Rettig's comments of a few weeks ago about defsystem for some
good points about this).
Incidentally (and now I am really drifting off into the sunset), I
believe that one reason Windows uses the BSD socket API is that at
least some versions of Windows used the BSD socket *code*. Even more
amusingly, I remember (not that long ago) when if you telneted to
ftp.microsoft.com you got a login prompt from a BSD/OS machine!
--tim
On 15 Jun 2001 17:49:49 +0100, Tim Bradshaw <···@tfeb.org> wrote:
> Incidentally (and now I am really drifting off into the sunset), I
> believe that one reason Windows uses the BSD socket API is that at
> least some versions of Windows used the BSD socket *code*. Even more
I seem to remember that Microsoft added to Windows the WinSock standard
that had been created by a group of independent developers.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Paolo Amoroso" <·······@mclink.it> wrote in message
·································@4ax.com...
> On 15 Jun 2001 17:49:49 +0100, Tim Bradshaw <···@tfeb.org> wrote:
>
> > Incidentally (and now I am really drifting off into the sunset), I
> > believe that one reason Windows uses the BSD socket API is that at
> > least some versions of Windows used the BSD socket *code*. Even more
>
> I seem to remember that Microsoft added to Windows the WinSock standard
> that had been created by a group of independent developers.
The Microsoft TCP/IP stack was based on the FreeBSD TCP/IP stack. People
looked at the strings and found word-for-word matches. Not to get into a
huge open source debate, the BSD license allowed Microsoft to incorporate
and extend the stack without making their code public. This is the same
reason that OS/X's underlying UNIX is FreeBSD and not LINUX.
faa
Paolo Amoroso wrote:
>
> On 15 Jun 2001 17:49:49 +0100, Tim Bradshaw <···@tfeb.org> wrote:
>
> > Incidentally (and now I am really drifting off into the sunset), I
> > believe that one reason Windows uses the BSD socket API is that at
> > least some versions of Windows used the BSD socket *code*. Even more
>
> I seem to remember that Microsoft added to Windows the WinSock standard
> that had been created by a group of independent developers.
>
True enough. And, it does depart from BSD in several important respects
because of that.
However, it is surprisingly easy for most Sockets' apps to live with both
the Microsoft and regular BSD style conventions. The worst of it is that
Winsock seems to have cut out a few low level interfaces that sometimes
are very useful. But, if one stays at the higher OSI levels, it isn't too
hard to deal with both. The most annoying part is some gratuitous renaming
of return codes (that, in my experience of them, have an identical semantic).
Still, compared to even textbook examples I have seen of LISP variability,
the variability here is not as great. Or else, the unity is easier for me to see
in a language I know better. Even in the very variable GUI API world, there's
more unity than meets the eye across a sea of variant APIs -- enough so that
I could straddle Mac and Windows without tremendous trauma and without
excessive IFDEFs.
Larry
Larry Loen <······@us.ibm.com> writes:
> However, it is surprisingly easy for most Sockets' apps to live with both
> the Microsoft and regular BSD style conventions.
Have you ever tried to do something with the BSD style socket API
where you really needed to have control? Like getting the ISC dhcpd
implementation to run on platforms the developers don't use themselves
like AIX? All dhcpd does in a nutshell is listen to UDP broadcasts and
sending a broadcast reply. To code this you need OS specific code
that's different for AIX 3.x, AIX 4.1 and AIX 4.3 and occasionaly you
need to know the exact patches applied to the machine since they make
a difference. Stevens' books on network programming have hundreds of
pages filled with description of how various implementations of this
API behave under different circumstances. Doing anything not trivial
like dealing with OOB and error conditions is not at all
standardized. So if you want the situation of the C world, yes we
could agree on what the functions are called. You'd still have to find
out for yourself what they do though.
--
Lieven Marchand <···@wyrd.be>
Making laws appears to win votes. Enforcing them doesn't.
See Rule One. Roger Burton West in the monastery.
Lieven Marchand wrote:
>
[snip]
> Have you ever tried to do something with the BSD style socket API
> where you really needed to have control? Like getting the ISC dhcpd
No, apparently not. Things I have done have been by-hand versions of mail, news, and SNTP (UDP-based, of course, in the last case, the
rest TCP). I've never needed particularly low-level interfaces to do these kinds of things. Now, if I had to write my own port
forwarder and so on, I'd have a lot more sympathy for your argument from my own experience. However, so far, most of what I've needed
to do has been to wrapper my own code around fairly basic, standard functions.
Perhaps there are two classes of sockets app -- someone who is basically doing system programming and otherwise doing lower level
protocols and those who are simply taking over the higher levels to invoke very standard functions (stuff you can almost do with input
redirection on standard commands to a mailer or FTP or something). I seem to be of the latter type, so far.
Larry
Larry Loen <······@us.ibm.com> writes:
> Lieven Marchand wrote:
> >
> [snip]
> > Have you ever tried to do something with the BSD style socket API
> > where you really needed to have control? Like getting the ISC dhcpd
>
> No, apparently not. Things I have done have been by-hand versions of mail, news, and SNTP (UDP-based, of course, in the last case, the
> rest TCP). I've never needed particularly low-level interfaces to do these kinds of things. Now, if I had to write my own port
> forwarder and so on, I'd have a lot more sympathy for your argument from my own experience. However, so far, most of what I've needed
> to do has been to wrapper my own code around fairly basic, standard functions.
But even the basic standard functions are ill specified. The example
has already been given: the semantics of the second argument to
listen(2). It should be the maximum number of pending connections
allowed. W. Richard Stevens needs 5 pages in 'Unix Network
Programming, Volume 1, 2nd. Edition' to describe in detail what
various implementations mean by this parameter, including a table
detailing actual number of queued connections versus value of backlog
parameter for 6 Unix variants. For amusement value, for a parameter
value of 12 the actual values are 19, 12, 18, 8, 13 and 19.
For the things you need porting between the various vendors API is
trivial and if you want to write to a common API you can use the clocc
net modules.
--
Lieven Marchand <···@wyrd.be>
Making laws appears to win votes. Enforcing them doesn't.
See Rule One. Roger Burton West in the monastery.
Tim Bradshaw wrote:
>
[snip]
>
> This is getting pretty offtopic, but I think we often forget that CL
> has an unusually high number of implementations. From where I'm
> sitting I have access to four near-ANSI implementations intended for
"near-ANSI" is an intriguing statement. Does this mean no one quite
can bring themselves to follow the standard? This is probably not
unique to LISP, but is there (say) a compliance suite for COMMON LISP
with some report one could look up if a given vendor falls short, and
where?
> serious use, three of which are commercial implementations of very
> good quality, and the fourth is CMUCL which is not commercial but also
> pretty serious. On my machines I have at home I have three near-ANSi
> implementations (one commercial) and gcl on solaris, and two (both
> commercial) on Windows, as well as genera, which is also near-ANSI.
> And I'm not trying too hard - I don't have CLISp on windows for
> instance. For comparison, I've never used a machine with more than two
> C compilers.
>
But, two compilers should be enough to have comparable problems. And,
two are fairly commonplace. Intriguingly, the OS and machine seem to
me a greater source of variability in C than the two compilers, even
if from very different vendors. Thus, I worry more about getting
code to compile on Platform X and worry very little about Compiler
Y if I switch, which I have been known to do.
Maybe LISP is high enough level as a language that "How to Avoid
Portability Problems" is less obvious than not depending on sizeof(void)
equals sizeof(int)?
> Given this, and given that Lisp implementations are not typically
> bound into the OS in the way that C implementations are (Genera being
> a notable exception, of course), I think it's fairly easy to see why
> there are multiple APIs to things and why unification is not easy.
> That doesn't mean unification is not desirable - I think it is, so
> long as it's unification around a standard which is acceptable (see
> Duane Rettig's comments of a few weeks ago about defsystem for some
> good points about this).
>
I can see why unification is not easy. But, as Java shows,
there is at least the possibility of a pretty highly standard
outcome for at least one language in the world with a similar set
of problems and just enough abstraction that it can't claim machine
variability as an excuse. Maybe such standardization
would have other bad effects on the LISP world that aren't
apparent, though.
> Incidentally (and now I am really drifting off into the sunset), I
> believe that one reason Windows uses the BSD socket API is that at
> least some versions of Windows used the BSD socket *code*. Even more
> amusingly, I remember (not that long ago) when if you telneted to
> ftp.microsoft.com you got a login prompt from a BSD/OS machine!
>
> --tim
There are some BSD interfaces that virtually everyone seems to
have decided to license from BSD. Why this was the outcome, I
don't know, but the variation (in this set of interfaces at least)
is about as low as C could be expected to deliver for such a high
performance circumstance. It does suggest that standardization
can happen in places one might not initially expect. For C,
this is a place I'd have predicted more variability. Why there
is (relative) unity here and not in GUI, for instance, would
make a pretty Ph. D. theses in some psychological or anthroprological
discipline.
What I'm curious about is the theme this newbie sees that virtually
nothing beyond COMMON Lisp (or Scheme, for that matter) appears to be
standard. Perhaps this, too, is more like other languages than
meets the eye, but for all its defects, things like the Java Community
Process seems to be churning out some fairly standard libraries for
a lot of stuff. Is there a corresponding structure for LISP? Does
it produce fewer than five interfaces for other things beyond this
one (amybe exceptional?) example of sockets?
The most intimidating part for any newbie in any language is,
after having mastered basic syntax and hello world, to be given
a large stack of APIs to read up on. If that stack is multiplied by
a factor of five due to lack of unity, it will certainly be a factor
in the language's health.
Larry
Larry Loen <······@us.ibm.com> writes:
> Maybe LISP is high enough level as a language that "How to Avoid
> Portability Problems" is less obvious than not depending on sizeof(void)
> equals sizeof(int)?
Well, yes. The more a language does, the more places there are that
two implementations of it can differ. My observation from outside is
that even C++ has this problem, as soon as you start trying to use
any of the stuff like templates or the STL.
> What I'm curious about is the theme this newbie sees that virtually
> nothing beyond COMMON Lisp (or Scheme, for that matter) appears to be
> standard.
Well, I can think of Gray Streams and the MOP as two counter-examples.
It's unusual to get an implementation that won't support them these days.
(Await followup from Duane Rettig describing why simple-streams are
better anyway ...)
Ten minutes web browsing suggests that CLX works in most
implementations that run on platforms that are typically used with X.
CLIM is perhaps a little less widespread (not yet any good free
implementation - though McCLIM is actively being worked on) but that's
probably a candidate too.
I'd guess that the requirements of CLIM-SYS and CL-HTTP mean that most
implementations with a threading interface have pretty similar APIs to
them. (Await followup from Tim Bradshaw describing why it would be
suicidal to standardise on any API which exports WITHOUT-SCHEDULING ...)
There are two independent implementations of the Allegro NET.URI API,
and likewise for the Xanalys Common SQL. In both cases, the second
implementation is freeely available
So, granted it's not a perfect world, but I don't think it's quite as
bleak as you paint it either.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> > What I'm curious about is the theme this newbie sees that virtually
> > nothing beyond COMMON Lisp (or Scheme, for that matter) appears to be
> > standard.
>
> Well, I can think of Gray Streams and the MOP as two counter-examples.
> It's unusual to get an implementation that won't support them these days.
The CL CORBA binding is also standardized. It was a multi-vendor effort.
> (Await followup from Duane Rettig describing why simple-streams are
> better anyway ...)
This would be redundant. Instead, I'll once again provide the url that
describes what you are looking for.
http://www.franz.com/support/documentation/6.0/doc/streams.htm
See especially all of section 2.
--
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)
Daniel Barlow wrote:
> Well, I can think of Gray Streams and the MOP as two counter-examples.
> [to portability woes] It's unusual to get an implementation that won't support them these days.
> (Await followup from Duane Rettig describing why simple-streams are
> better anyway ...)
>
> Ten minutes web browsing suggests that CLX works in most
> implementations that run on platforms that are typically used with X.
> CLIM is perhaps a little less widespread (not yet any good free
> implementation - though McCLIM is actively being worked on) but that's
> probably a candidate too.
>
[snip more]
So, maybe the issue is one of integration? I have to get CLISP from here
CLIM from there Gray Streams from over there?
Maybe there's a reason Commercial LISPs exist?? Hm. . . .
Larry
On Mon, 18 Jun 2001 13:47:55 -0500, Larry Loen
<······@rchland.vnet.ibm.com> wrote:
> So, maybe the issue is one of integration? I have to get CLISP from here
> CLIM from there Gray Streams from over there?
Both CMU CL and CLISP ship with Gray streams support.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Daniel Barlow <···@telent.net> writes:
> (Await followup from Tim Bradshaw describing why it would be
> suicidal to standardise on any API which exports WITHOUT-SCHEDULING ...)
>
It would be ... damn, am I that predictable?
Actually, the MOP is a pretty good example of something which seems to
be effectively there as you say. CLISP is the only implementation
which really doesn't seem to have it, and CMUCL requires (required?)
you to jump through some package-hacking hoops to get things to work.
--tim
On 18 Jun 2001 15:36:51 +0100, Tim Bradshaw <···@tfeb.org> wrote:
> Actually, the MOP is a pretty good example of something which seems to
> be effectively there as you say. CLISP is the only implementation
> which really doesn't seem to have it, and CMUCL requires (required?)
Although CLISP does not ship with MOP support, PCL is available for it.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Larry Loen <······@us.ibm.com> writes:
>
> "near-ANSI" is an intriguing statement. Does this mean no one quite
> can bring themselves to follow the standard? This is probably not
> unique to LISP, but is there (say) a compliance suite for COMMON LISP
> with some report one could look up if a given vendor falls short, and
> where?
I realised I phrased this badly after I posted. `Near ANSI' meant
`within a short distance of ANSI, including completely ANSI'.
Basically I didn't want to rule out things with known, small,
non-compliances, but I did want to rule out GCL or elisp.
>
> But, two compilers should be enough to have comparable problems. And,
> two are fairly commonplace. Intriguingly, the OS and machine seem to
> me a greater source of variability in C than the two compilers, even
> if from very different vendors. Thus, I worry more about getting
> code to compile on Platform X and worry very little about Compiler
> Y if I switch, which I have been known to do.
No, C is a special case. C systems are so tightly bound to the OS
that they almost always have the same API for a given OS(-family).
Indeed they often use the same libraries (when I say -lnsl -lsocket to
gcc I'm picking up Sun-supplied libraries).
C is a bad choice of comparison, I just couldn't think of any other
language (other than scheme) I've ever used where there was more than
one implementation on a given machine.
If you don't get shafted by compiler differences you must write good
C! This is not meant to doubt that you do - lots of people don't
though. C++ is a more interesting case I think - a lot of people I
knew a few years ago seemed to live in a perpetual nightmare of
compiler variability.
> I can see why unification is not easy. But, as Java shows,
> there is at least the possibility of a pretty highly standard
> outcome for at least one language in the world with a similar set
> of problems and just enough abstraction that it can't claim machine
> variability as an excuse. Maybe such standardization
> would have other bad effects on the LISP world that aren't
> apparent, though.
The only java programs I've ever used have been just ludicrously
machine-dependent (pretty much they run on Windows, not Suns). But
maybe I've been unlucky.
> There are some BSD interfaces that virtually everyone seems to
> have decided to license from BSD. Why this was the outcome, I
> don't know, but the variation (in this set of interfaces at least)
> is about as low as C could be expected to deliver for such a high
> performance circumstance. It does suggest that standardization
> can happen in places one might not initially expect. For C,
> this is a place I'd have predicted more variability. Why there
> is (relative) unity here and not in GUI, for instance, would
> make a pretty Ph. D. theses in some psychological or anthroprological
> discipline.
Oh, that's easy. People didn't licence them, they just used the code.
The BSD license lets you do that pretty painlessly.
>
> What I'm curious about is the theme this newbie sees that virtually
> nothing beyond COMMON Lisp (or Scheme, for that matter) appears to be
> standard. Perhaps this, too, is more like other languages than
> meets the eye, but for all its defects, things like the Java Community
> Process seems to be churning out some fairly standard libraries for
> a lot of stuff. Is there a corresponding structure for LISP? Does
> it produce fewer than five interfaces for other things beyond this
> one (amybe exceptional?) example of sockets?
Well I think you need to compare things carefully. There are
single-implementation languages where even if there are multiple APIs
they all run in the same implementation so you can choose one. There
are languages like Java where large companies are pumping millions of
dollars into generating (formal or de-facto) standard libraries.
There are languages like C which tend to expose OS APIs. For the
latter languages the OS being exposed is either a single
implementation (Windows, which isn't really, and the APIs aren't that
standard in fact, but you do what MS want), or multi-implementation,
where there is usually a common core, and then either just variability
(common on a lot of Unix APIs), or a big standards process which is
costing someone a lot of money (also common in Unix APIs). And
finally there are multi-implementation languages which are not tightly
OS-bound and where no-one is pumping millions of dollars into
standards (either formal or de-facto).
I think the trick is to work out how to generate standard APIs without
throwing huge money at it. I think that is hard. I'd like to see it
happen but I need to get paid: I simply don't have that much time to
spend on things which I don't get paid for. I suspect that this is
true for others too (as in: I'd be surprised if it was not). If
someone wants to stump up money to support an informal standards
process, that would be great, of course (mail me!).
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Larry Loen <······@us.ibm.com> writes:
>
> >
> > "near-ANSI" is an intriguing statement. Does this mean no one quite
> > can bring themselves to follow the standard? This is probably not
> > unique to LISP, but is there (say) a compliance suite for COMMON LISP
> > with some report one could look up if a given vendor falls short, and
> > where?
>
> I realised I phrased this badly after I posted. `Near ANSI' meant
> `within a short distance of ANSI, including completely ANSI'.
> Basically I didn't want to rule out things with known, small,
> non-compliances, but I did want to rule out GCL or elisp.
I took your interesting phrasing to be the equivalent of the
phrase "purports to conform" (a dictionary entry in the spec).
Perhaps you meant something different, but usage of this
standard phrase accomplishes the same goal.
--
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)
Duane Rettig <·····@franz.com> writes:
>
> I took your interesting phrasing to be the equivalent of the
> phrase "purports to conform" (a dictionary entry in the spec).
> Perhaps you meant something different, but usage of this
> standard phrase accomplishes the same goal.
>
That wasn't quite what I meant I think. My interpretation of PtC is
that non-conformance is a bug, whereas what I meant was an
implementation which might say:
`we conform to ANSI except that we haven't implemented gribblers, and
we don't intend to and we don't think this is a bug, we just hate
gribblers', some suitable small value of gribblers. Such an
implementation for instance would probably not put :x3j13 on
*features* (if it did, this would be a bug I think...), but I wanted
to include it.
I haven't use CLISP for a while but if I remember it intentionally
didn't support various redefinition-type things in CLOS and this would
make it be near-ANSi but not Ptc in my book. (Forgive me if I am being
unfair to CLISP here: that is not my intention.)
--tim
Tim wrote:
> That wasn't quite what I meant I think. My interpretation of PtC is
> that non-conformance is a bug, whereas what I meant was an
> implementation which might say:
>
> I haven't use CLISP for a while but if I remember it intentionally
> didn't support various redefinition-type things in CLOS and this would
> make it be near-ANSi but not Ptc in my book. (Forgive me if I am being
> unfair to CLISP here: that is not my intention.)
More than this, this is also a little unfair, in as much as, you
can replace the default CLOS and install PCL that will compile
with clisp that will give you all the redefinition-type things to
your hearts content -- within the limitations of PCL.
:)will
Tim Bradshaw wrote:
[snip]
>
> The only java programs I've ever used have been just ludicrously
> machine-dependent (pretty much they run on Windows, not Suns). But
> maybe I've been unlucky.
>
If my experience is any guide, yes you have.
Speaking of my personal code, it has all ported without notable incident all over the place. Other Java stuff I've tried has been pretty darn
portable. Perhaps, in the larger apps I've played with, there is a little bit of "if (os.name=="Windows") in it that no one told me about, but the
behavior of even large apps is such that I doubt there is much of that. And, I almost always run Java on multiple platforms, more than once with
little advance warning to the originator. Certainly, I've found model/OS dependencies fairly easy to avoid in my own code, even for GUI-based stuff.
> > What I'm curious about is the theme this newbie sees that virtually
> > nothing beyond COMMON Lisp (or Scheme, for that matter) appears to be
> > standard. Perhaps this, too, is more like other languages than
> > meets the eye, but for all its defects, things like the Java Community
> > Process seems to be churning out some fairly standard libraries for
> > a lot of stuff. Is there a corresponding structure for LISP? Does
> > it produce fewer than five interfaces for other things beyond this
> > one (amybe exceptional?) example of sockets?
[snip]
> I think the trick is to work out how to generate standard APIs without
> throwing huge money at it. I think that is hard. I'd like to see it
> happen but I need to get paid: I simply don't have that much time to
> spend on things which I don't get paid for. I suspect that this is
> true for others too (as in: I'd be surprised if it was not). If
> someone wants to stump up money to support an informal standards
> process, that would be great, of course (mail me!).
>
Yes, in my experience of it standards, at least when serious technical issues are on the table, are expensive. You have to hire some of your best
folk, cheerfully kiss off a year or two of their productive careers, put up the plane fare to let them meet at least quarterly. And, even then,
nothing is certain (except that success, if you get it, is worth lots of bucks). Now, that's expensive all the way around!
Larry
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>Larry Loen <······@us.ibm.com> writes:
>>
>> But, two compilers should be enough to have comparable problems. And,
>> two are fairly commonplace. Intriguingly, the OS and machine seem to
>> me a greater source of variability in C than the two compilers, even
>> if from very different vendors. Thus, I worry more about getting
>> code to compile on Platform X and worry very little about Compiler
>> Y if I switch, which I have been known to do.
>
>No, C is a special case. C systems are so tightly bound to the OS
>that they almost always have the same API for a given OS(-family).
>Indeed they often use the same libraries (when I say -lnsl -lsocket to
>gcc I'm picking up Sun-supplied libraries).
>
The OS APIs are usually defined in C, which makes it easier.
However, this API is available for any system that can call C
functions. It isn't necessarily pretty, but lots of the C code
out there isn't pretty either.
(BTW, the Macintosh API used to be defined for 68K assembler
and Pascal. I *think* the two earliest C compilers, MPW and
Think, had different ways of accessing them, but I didn't use
MPW then and can't be sure.)
So, if you want to have a standard socket API, write FFI definitions
for every CL system you wish to include. It's more work, but
it's just as effective as the C way of doing it. These will
also use the same library. (Alternatively, write a system that
takes a list of C prototypes and the name of a CL system, and
produces a set of function definitions for that CL. Poof!
Instant C-style compatibility!)
>C is a bad choice of comparison, I just couldn't think of any other
>language (other than scheme) I've ever used where there was more than
>one implementation on a given machine.
>
The first time I ran into that there were three FORTRAN 66 compilers
on the machine. I've seen other examples. (Right now, I've got
at least two, and I think three, JVMs on my machine.)
>If you don't get shafted by compiler differences you must write good
>C! This is not meant to doubt that you do - lots of people don't
>though. C++ is a more interesting case I think - a lot of people I
>knew a few years ago seemed to live in a perpetual nightmare of
>compiler variability.
>
There was a good deal of change in the last part of the standardization
process, meaning that vendors were struggling to keep up. Now that
there's been a stable standard for a few years, it's becoming
easier. C++ keeps all the system-dependent stuff about C and
adds things like template instantiation, so you do have to be
careful.
>
>> There are some BSD interfaces that virtually everyone seems to
>> have decided to license from BSD. Why this was the outcome, I
>>
>> this is a place I'd have predicted more variability. Why there
>> is (relative) unity here and not in GUI, for instance, would
>> make a pretty Ph. D. theses in some psychological or anthroprological
>> discipline.
>
>Oh, that's easy. People didn't licence them, they just used the code.
>The BSD license lets you do that pretty painlessly.
>
In this case, the socket layer can be compared to the X layer. You
can write a program using the Motif widgets and run it on a lot
of platforms (you may have to pay for X implementations on some
platforms, such as the Mac). Alternatively, you can use toolkits
like Tk and wxWindows, which run at least on MS Windows, the Mac,
and X.
The difference in GUIs is more a matter of divergent design, and
the fact that GUI manufacture using primitives is sufficiently
painful that everybody comes up with some way to make it less
painful. Further, it's much more visible to the user. You
won't make or lose many sales depending on how clunky your
socket code is, but you will have trouble selling apps that
look like MS Windows to Macintosh users.
>I think the trick is to work out how to generate standard APIs without
>throwing huge money at it. I think that is hard. I'd like to see it
>happen but I need to get paid: I simply don't have that much time to
>spend on things which I don't get paid for. I suspect that this is
>true for others too (as in: I'd be surprised if it was not). If
>someone wants to stump up money to support an informal standards
>process, that would be great, of course (mail me!).
>
Is it possible to convert C prototypes into Lisp FFI calls automatically,
for every CL? In that case, with a bit of work you've got APIs that
are as standard, and usable, as the C APIs.
If this is not a good solution, then perhaps it's because Lisp
people want better solutions than C people do. In that case, it's
a matter of how you want to wrap up the raw functionality, and
that's more of a design problem than a compatibility problem.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
David Thornley <········@visi.com> wrote:
+---------------
| So, if you want to have a standard socket API, write FFI definitions
| for every CL system you wish to include. It's more work, but
| it's just as effective as the C way of doing it. These will
| also use the same library. (Alternatively, write a system that
| takes a list of C prototypes and the name of a CL system, and
| produces a set of function definitions for that CL. Poof!
| Instant C-style compatibility!)
+---------------
It's not that simple, since you almost certainly want (for example)
the "select()" system call to properly interact with any threading
that's built into your CL, and *that's* not likely to be a "small
matter of FFI".
By "select() properly interact with threading", I mean that if one
thread in your Lisp program does a blocking read on a terminal and
another does a blocking read on a socket, "the right thing" happens
(that is, the correct thread immediately wakes and completes the read)
regardless of which device produces data first. Getting this right across
multiple implementations if you've written the socket access through
an FFI (but you're using the built-in file I/O for terminals!) is
likely to be... well... interesting.
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
>>>>> "RW" == Rob Warnock <····@rigden.engr.sgi.com> writes:
[...]
RW> By "select() properly interact with threading", I mean that if
RW> one thread in your Lisp program does a blocking read on a
RW> terminal and another does a blocking read on a socket, "the
RW> right thing" happens (that is, the correct thread immediately
RW> wakes and completes the read) regardless of which device
RW> produces data first. [...]
Hmm. Do MP lisps handle this at all? I'd assumed they were using
some user space infra-structure so if a syscall blocks, everything
blocks (mod signal/syscall issues). Do you mean some magic (neat
programming) happens and lisp stream functions get funneled through a
select loop and non-blocking IO syscalls? But if you actually have
that, waking up the right thread should be no problem. I assume I am
missing something?
thanks,
BM
On Thu, 21 Jun 2001, Bulent Murtezaoglu wrote:
> >>>>> "RW" == Rob Warnock <····@rigden.engr.sgi.com> writes:
> [...]
> RW> By "select() properly interact with threading", I mean that if
> RW> one thread in your Lisp program does a blocking read on a
> RW> terminal and another does a blocking read on a socket, "the
> RW> right thing" happens (that is, the correct thread immediately
> RW> wakes and completes the read) regardless of which device
> RW> produces data first. [...]
>
> Hmm. Do MP lisps handle this at all? I'd assumed they were using
> some user space infra-structure so if a syscall blocks, everything
> blocks (mod signal/syscall issues). Do you mean some magic (neat
> programming) happens and lisp stream functions get funneled through a
> select loop and non-blocking IO syscalls? But if you actually have
> that, waking up the right thread should be no problem. I assume I am
> missing something?
Well, that's the point; if MP is implemented at a fairly high level in the
Lisp, e.g. as non-blocking read/write functions that sit right below
streams, it's going to be hard to do a blocking select in a portable
manner. This method seems to be common.
On the other hand, if MP is implemented atop a native threads
implmentation, e.g. POSIX threads, then you can in theory call blocking
system calls all you want. Other than ACL on Windows I don't know of any
lisps that don't roll their own MP.
Tim
Bulent Murtezaoglu <··@acm.org> writes:
>
> Hmm. Do MP lisps handle this at all? I'd assumed they were using
> some user space infra-structure so if a syscall blocks, everything
> blocks (mod signal/syscall issues). Do you mean some magic (neat
> programming) happens and lisp stream functions get funneled through a
> select loop and non-blocking IO syscalls? But if you actually have
> that, waking up the right thread should be no problem. I assume I am
> missing something?
>
I think that allegro, at least, does the right thing here. I'd expect
other good quality implementations to as well, as it makes doing a lot
of things very hard if it doesn't work right.
--tim
Bulent Murtezaoglu <··@acm.org> wrote:
+---------------
| "RW" == Rob Warnock <····@rigden.engr.sgi.com> writes:
| RW> By "select() properly interact with threading", I mean that if
| RW> one thread in your Lisp program does a blocking read on a
| RW> terminal and another does a blocking read on a socket, "the
| RW> right thing" happens (that is, the correct thread immediately
| RW> wakes and completes the read) regardless of which device
| RW> produces data first. [...]
|
| Hmm. Do MP lisps handle this at all?
+---------------
Dunno 'bout multiprocessor (which is what I assume "MP" means), but
some multithreaded systems do. [I said "systems", rather than "Lisps",
for soon-to-be-obvious reasons...]
+---------------
| I'd assumed they were using some user space infra-structure so if
| a syscall blocks, everything blocks (mod signal/syscall issues).
| Do you mean some magic (neat programming) happens and lisp stream
| functions get funneled through a select loop and non-blocking IO
| syscalls?
+---------------
Yes, MzScheme threads do precisely that. If a read in one thread would
block, the read is deferred, the thread is de-scheduled, and the low-level
file descriptor is added to the bit-mask of a system-maintained common
"select()" call that's done when there's nothing else runnable.
+---------------
| But if you actually have that, waking up the right thread should be
| no problem. I assume I am missing something?
+---------------
Waking up the right thread for system-defined I/O is no problem, but
remember we were talking about "bolting on" socket I/O with an FFI.
My question was whether each multithreaded system provided a clean
way for such FFI-added code to participate in the "select()" magic.
For example, MzScheme provides to extension programmers a
"scheme_block_until()" function:
<URL:http://www.cs.rice.edu/CS/PLT/packages/doc/insidemz/node29.htm>
...
This procedure takes two functions: a polling function that
tests whether the blocking operation can be completed, and a
prepare-to-sleep function that sets bits in fd_sets when MzScheme
decides to sleep (because all MzScheme threads are blocked).
And for callbacks going the other way, it has "scheme_wakeup_on_input()":
<URL:http://www.cs.rice.edu/CS/PLT/packages/doc/insidemz/node31.htm>
I would hope that all the Common Lisps that have threads have something
similar. The point I was trying to make to the OP was that to add something
like sockets, you *can't* just "bolt it on" with an FFI and expect it
to "play nice" with the rest of the system unless you find out what
system-dependent thread and non-blocking I/O features exist and then
make your FFI-added code work with them.
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
In article <··············@fido.engr.sgi.com>,
Rob Warnock <····@rigden.engr.sgi.com> wrote:
>David Thornley <········@visi.com> wrote:
>+---------------
>| So, if you want to have a standard socket API, write FFI definitions
>| for every CL system you wish to include. It's more work, but
>| it's just as effective as the C way of doing it. These will
>| also use the same library. (Alternatively, write a system that
>| takes a list of C prototypes and the name of a CL system, and
>| produces a set of function definitions for that CL. Poof!
>| Instant C-style compatibility!)
>+---------------
>
>It's not that simple, since you almost certainly want (for example)
>the "select()" system call to properly interact with any threading
>that's built into your CL, and *that's* not likely to be a "small
>matter of FFI".
>
Is it any simpler with C? That's the point I'm addressing.
I don't see that CL has any disadvantage relative to C in
APIs that can't be corrected by a bit of fiddling with FFI.
>By "select() properly interact with threading", I mean that if one
>thread in your Lisp program does a blocking read on a terminal and
>another does a blocking read on a socket, "the right thing" happens
>(that is, the correct thread immediately wakes and completes the read)
>regardless of which device produces data first. Getting this right across
>multiple implementations if you've written the socket access through
>an FFI (but you're using the built-in file I/O for terminals!) is
>likely to be... well... interesting.
>
How is this done in C? It's got to be a problem no matter which
language you're working in.
If you're working with Posix threads, and you are writing a program
in C that does a blocking read on a terminal in one thread and
a blocking read on a socket in another, is there a clean way
to write this so that it will do the same thing across different
Unix-based operating systems? If there is one, then I'm wrong.
If, as I suspect, this requires some hairy code, some of which
is system-dependent, then I don't really see that C has a
great advantage here.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
David Thornley <········@visi.com> wrote:
+---------------
| Rob Warnock <····@rigden.engr.sgi.com> wrote:
| >It's not that simple, since you almost certainly want (for example)
| >the "select()" system call to properly interact with any threading
| >that's built into your CL, and *that's* not likely to be a "small
| >matter of FFI".
|
| Is it any simpler with C? That's the point I'm addressing.
| I don't see that CL has any disadvantage relative to C in
| APIs that can't be corrected by a bit of fiddling with FFI.
+---------------
The point was that the *system* (Common Lisp, Scheme, Python, whatever)
probably already has some internally-defined way of handling the
interactions between threads and I/O so as to make thread-local
blocking I/O actually be *non*-blocking in the application as a
whole. The question is whether those facilities have been exposed
to the FFI facility in such a way that you the user can write FFI-based
extensions that "play nice" with those internally-defined non-blocking
I/O facilities. (Without having to go digging around in the source code
of the Lisp system... which you might very well not have available!)
+---------------
| How is this done in C? It's got to be a problem no matter which
| language you're working in.
+---------------
It's not so much a language issue per se, as an application system
issue. For example, if you're trying to write an X Windows application
that also does socket reads/write to some other server (say, a database)
and you don't want mouse events to be locked out while you're waiting
for a remote server response, you're going to have to "play nice" with
the X event loop. [Now fortunately, the Xt Intrisics provide this nice
little "XtAddInput(unix_fd, reason, function, data)" that you can use.]
But you get the idea. In any Lisp system you want to be able to add
FFI-based I/O stuff to, you're going to need to find out the equivalent
of "XtAddInput()" for that system's thread/non-blocking-I/O management,
and use that in your FFI code.
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
Carl Shapiro wrote:
>
> "Wade Humeniuk" <········@cadvision.com> writes:
>
> > You are right. It is time for me to face the reality of the situation.
> > This is probably the only programming language that has five or more
> > completely different APIs for sockets. That is the reality.
>
> There are "five or more" completely different interfaces to sockets in
> C, Smalltalk, APL, and just about every other language out there which
> has more that one implemenation or runs on more than one operating
> system. I don't think Common Lisp any worse off than anybody else in
> this regard.
If there is more than one for Java, at least, I've never seen it.
Moreover, I don't know of "five" for even C. I know of about two
and the only reason it seems like more is that C is a low enough
level language that it has all these little "impedance" matching
problems with the underlying hardware it sits pretty much atop.
Perhaps the real problem is the relative equality here? No doubt,
someone in this august group will recite to me ObscurityWorks' alternate
Sockets package for Java and three wholly different C Sockets libraries
I've never heard of. However, I would take leave to doubt they
have much use or acceptance. Meanwhile, I have yet to see someone
say "well, 90 per cent of us use this set of APIs, so you can ignore
the rest" when it comes to LISP and sockets.
There are two paths to having a standard: A dominant implementation
that gets adopted and a standards committee. When neither happen,
then a hundred flowers bloom. This is hardly unique to LISP, but
it does seem to be a commonplace outcome, or so it looks to this
newbie.
Larry
Larry Loen <······@us.ibm.com> writes:
> Moreover, I don't know of "five" for even C. I know of about two
> and the only reason it seems like more is that C is a low enough
> level language that it has all these little "impedance" matching
> problems with the underlying hardware it sits pretty much atop.
If you are not doing anything interesting, the various socket
interfaces may look the same. However, when doing more interesting
things with sockets (for example, queued i/o, i/o multiplexing, or
using protocols other than TCP) the various socket packages start to
look awfully different.
Maybe I am just completely lost, but socket interfaces seem closely
tied to the i/o model your sitting on top of, which varies wildly
between operating systems. Java may only have one socket package, but
it has a really ho-hum, lowest common denominator i/o model as well.
Carl Shapiro wrote:
> Larry Loen <······@us.ibm.com> writes:
>
> > Moreover, I don't know of "five" for even C. I know of about two
> > and the only reason it seems like more is that C is a low enough
> > level language that it has all these little "impedance" matching
> > problems with the underlying hardware it sits pretty much atop.
>
> If you are not doing anything interesting, the various socket
> interfaces may look the same. However, when doing more interesting
> things with sockets (for example, queued i/o, i/o multiplexing, or
> using protocols other than TCP) the various socket packages start to
> look awfully different.
>
> Maybe I am just completely lost, but socket interfaces seem closely
> tied to the i/o model your sitting on top of, which varies wildly
> between operating systems. Java may only have one socket package, but
> it has a really ho-hum, lowest common denominator i/o model as well.
Perhaps, but does the typical LISP programmer need to do anything that deep? Why does LISP need anything more complicated than what Java has? At
some point, one would think that the complexities are left to OS programmers and the odd application extension, but that one would not want to deal,
routinely, with all that low level dreck. I admit I haven't deployed really substantial stuff, but I can readily see that for many basic application
types, Java has entirely everything one would need for most purposes in TCP and UDP. In short, the 80/20 rule ought to apply.
Larry
Larry Loen <······@rchland.vnet.ibm.com> writes:
> Perhaps, but does the typical LISP programmer need to do anything
> that deep?
Well, I do. Maybe I'm atypical.
If all you want from a socket interface is straightforward stuff like
"open a tcp port and wait for connections" or "connect to www.foo.com
port 81 and give me a stream", it would take you maybe a couple of
hours to define wrappers for each socket API you wanted to use. In
fact, you could start by looking at cl-http, or at CLOCC PORT, or
possibly even at CLX, because the probability is that they already
have. CLOCC especially.
If you're not going to standardise the grungey stuff, it doesn't seem
to me like a standard interface is all _that_ valuable.
(And if you are going to standardise the grungey stuff, you still have
to worry about how to deal with the OS differences: for example, what
are the semantics of the second argument to listen(2)? You _can't_ do
all of this stuff portably)
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
>
>
> If you're not going to standardise the grungey stuff, it doesn't seem
> to me like a standard interface is all _that_ valuable.
>
Sure it is. Having a simple, standard way to do printf has probably saved more money than any single thing I could list. The routine gets the most
value from standardization, in fact. Of course, you could point out that printf isn't 100% standard (%ld comes to mind), but for at least 80% of the
printf statements ever coded (printf("My debug value is: %d\n")), it is pretty portable.
>
> (And if you are going to standardise the grungey stuff, you still have
> to worry about how to deal with the OS differences: for example, what
> are the semantics of the second argument to listen(2)? You _can't_ do
> all of this stuff portably)
>
So far, my Java stuff has managed the trick. Someone, somewhere is masking all that drek for me and doing some neat stuff in the process. For
instance, Winsock leaves out a few low level Sockets interfaces that Java requires. Someone has figured out some arcane invocation of the underlying
Windows support, without a doubt.
Larry
Larry Loen <······@rchland.vnet.ibm.com> writes:
> > If you're not going to standardise the grungey stuff, it doesn't seem
> > to me like a standard interface is all _that_ valuable.
> >
>
> Sure it is. Having a simple, standard way to do printf has probably
> saved more money than any single thing I could list. The routine
> gets the most value from standardization, in fact. Of course, you
> could point out that printf isn't 100% standard (%ld comes to mind),
> but for at least 80% of the printf statements ever coded (printf("My
> debug value is: %d\n")), it is pretty portable.
That's why FORMAT is in the standard, and hence 100% portable (modulo
bugs). There is a huge difference in universal utility between
formatted output and a simplified socket interface, though. There are
few kinds of programs you can write that don't need formatted output
at some time. There are copious amounts of programs you can write
without a simplified socket interface (including stuff that needs no
sockets and stuff like nmap, that needs very low-level access).
Furthermore the effort needed to implement and maintain FORMAT
yourself is vastly exceeding the effort needed to implement and
maintain an application-specific portable socket API (as I
demonstrated in my other post).
Since there are limited resources in the universe, you can't
standardize each and everything that some people might find useful in
some situation. Hence you have to prioritize. Most of this thread
has been about detailing why a number of people (who are current users
of CL systems) put little priority on this particular item. Obviously
you put higher priorities on a simplified socket API than e.g. I do.
If you put enough of a priority on this item to warrant expenditure of
resources on your part, then you are free to start bugging your
vendor(s) of choice about it. Once the pressure on them has risen to
the required level, a portable API will come about, at the cost of
several $100000.
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
Larry Loen <······@rchland.vnet.ibm.com> writes:
> Carl Shapiro wrote:
[...]
> > If you are not doing anything interesting, the various socket
> > interfaces may look the same. However, when doing more interesting
> > things with sockets (for example, queued i/o, i/o multiplexing, or
> > using protocols other than TCP) the various socket packages start to
> > look awfully different.
> >
[...]
> Perhaps, but does the typical LISP programmer need to do anything
> that deep? Why does LISP need anything more complicated than what
> Java has? At some point, one would think that the complexities are
> left to OS programmers and the odd application extension, but that
> one would not want to deal, routinely, with all that low level
> dreck. I admit I haven't deployed really substantial stuff, but I
> can readily see that for many basic application types, Java has
> entirely everything one would need for most purposes in TCP and
> UDP. In short, the 80/20 rule ought to apply.
Whenever the discussion on socket or threading APIs crops up, I tend
to cite the following numbers:
Our complete in-house HTTP/1.0+ server consists of around 3.5KLOC of
completely portable ANSI CL code. That excludes all content
generation stuff (such as HTML/XML stuff, etc.), since the server is
completely content and generation agnostic, i.e. all of that code just
deals with the HTTP protocol, URIs, MIME entity handling, etc.
The amount of platform specific code that is needed to port the server
to any one of currently 4 supported platforms (CMU CL MP, CMU CL
serve-event, LispWorks Win/Lin and ACL) is around 50 LOC each. That
includes multi-threading/event-serving, locking and socket
creation/accepting code. Porting to a new platform takes 2 maybe 4
hours, including reading up on the APIs.
I consider this to be indicative of one thing: Wildly differing
socket APIs are not a problem for real-life projects that do simple
(TCP) socket stuff. There are probably various reasons for this:
- If you do simple stuff, you can define your own lowest common
denominator, which while not suitable for a general API, will
work just fine for your project.
- Any serious TCP socket API will give you a stream object either on
accept or connect, which will work transparently with the standard
CL stream functions. So the only stuff that's implementation
dependend is the socket creation, accept/connect and accessor
stuff.
- Sockets themselves are part of a non-invasive technology, in that
the structure of the socket API will not unduly affect the structure
of many other parts of your code. The same isn't true for some
other stuff, like e.g. GUIs.
While a common API that would save us 20 of the 50 lines above would
be "nice to have", I don't think it is a problem that warrants a very
high priority at all.
Of course stuff that does non-trivial stuff with sockets will be much
more implementation dependend, but then that stuff already is very OS
and API dependend, as suggested by Carl Shapiro.
Personally, I'd be far more interested in tightening down some aspects
of the MOP, implementing simple-streams (or some suitably similar API)
across the board, creating an extensible DEFSYSTEM standard, etc.
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
"Wade Humeniuk" <········@cadvision.com> writes:
>
> You are right. It is time for me to face the reality of the situation.
> This is probably the only programming language that has five or more
> completely different APIs for sockets. That is the reality.
Indeed. Could this be because it's the only programming language which
is not either so closely tied to an OS that the OS's sockets
implementation and the language's are the same (C/Unix) or has
essentially a single implementation (the rest)?
If this stresses you, you can either design and implement a common
sockets interface (and optionally get some other people to implement
it too and then try to get it accepted as a standard), or pick an
implementation and screw up your eyes and pretend the others don't
exist, so you can pretend to be using perl or some other
single-implementation language.
--tim
> If this stresses you, you can either design and implement a common
> sockets interface (and optionally get some other people to implement
> it too and then try to get it accepted as a standard), or pick an
> implementation and screw up your eyes and pretend the others don't
> exist, so you can pretend to be using perl or some other
> single-implementation language.
I know what I have done in the past, and that is to screw up my eyes and
deal with the problem at hand.
Wade
"Wade Humeniuk" <········@cadvision.com> writes:
> I know what I have done in the past, and that is to screw up my eyes and
> deal with the problem at hand.
>
That's what I do too.
--tim
Tim Bradshaw wrote:
> "Wade Humeniuk" <········@cadvision.com> writes:
>
>>
>> You are right. It is time for me to face the reality of the situation.
>> This is probably the only programming language that has five or more
>> completely different APIs for sockets. That is the reality.
>
> Indeed. Could this be because it's the only programming language which
> is not either so closely tied to an OS that the OS's sockets
> implementation and the language's are the same (C/Unix) or has
> essentially a single implementation (the rest)?
>
> If this stresses you, you can either design and implement a common
> sockets interface (and optionally get some other people to implement
> it too and then try to get it accepted as a standard), or pick an
> implementation and screw up your eyes and pretend the others don't
> exist, so you can pretend to be using perl or some other
> single-implementation language.
So what is your opinion to the socket-stuff?
Do you find it a benefit that there are actually more Lisp socket-APIs
available than Lispimplementations?
What would _you_ prefer as a standard API for sockets. Would you use
a comunity defined socket API too if you find another API better?
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> So what is your opinion to the socket-stuff?
> Do you find it a benefit that there are actually more Lisp socket-APIs
> available than Lispimplementations?
> What would _you_ prefer as a standard API for sockets. Would you use
> a comunity defined socket API too if you find another API better?
I have no opinion on sockets worth repeating, I'm just trying to
explain why there are a lot of APIs when there aren't for C or perl,
for instance.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> I have no opinion on sockets worth repeating, I'm just trying to
> explain why there are a lot of APIs when there aren't for C or perl,
> for instance.
Perl has two, effectively. There's the functional one and the OO one
OK, this is off topic ...
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Tim Bradshaw wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> So what is your opinion to the socket-stuff?
>> Do you find it a benefit that there are actually more Lisp socket-APIs
>> available than Lispimplementations?
>> What would _you_ prefer as a standard API for sockets. Would you use
>> a comunity defined socket API too if you find another API better?
>
> I have no opinion on sockets worth repeating, I'm just trying to
> explain why there are a lot of APIs when there aren't for C or perl,
> for instance.
Hm...
I still do not really understand what this has to do with other languages.
We _have_ different APIs in Lisp and AFAIK this is ruled commonly as "not
good". So we should solve that problem. This topic has _nothing_ to do with
other languages and particularily not with C or Perl.
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> I still do not really understand what this has to do with other languages.
> We _have_ different APIs in Lisp and AFAIK this is ruled commonly as "not
> good". So we should solve that problem. This topic has _nothing_ to do with
> other languages and particularily not with C or Perl.
It has to do with explaining *why* we have multiple APIs, and why Lisp
is `the only language which has' (actually, it's not of course). If
you read my original message you'll have seen:
If this stresses you, you can either design and implement a common
sockets interface (and optionally get some other people to implement
it too and then try to get it accepted as a standard), or pick an
implementation and screw up your eyes and pretend the others don't
exist, so you can pretend to be using perl or some other
single-implementation language.
which is, I think, a suggestion as to a couple of ways to proceed. I
will happily admit to taking the second way, even though I'm
personally not stressed by having multiple APIs.
--tim
There's a difference between having different APIs that effectively
offer the same amount of functionality and having different APIs some
of which lack functionality altogether.
For example, in LispWorks there's this thing called
comm:start-up-server. By using this, you're locked into some details
about how they want you to do servers. Of course, sometimes this
works to your benefit. For example, when writing a simple TCP/IP
server, I use a macro that makes writing a server ultra-simple and
straight-forward. Here's a real example from some code:
(define-server :oms (stream *default-oms-port*)
(let ((*stream* stream))
(declare (special *stream*))
(loop
for form = (read stream nil :eof)
while (not (eq form :eof))
do (progn
;; the server should never receive data unless it is
;; waiting
(check-type *current-state* (not server-state))
;; all requests from the client must be conses
(check-type form cons)
;; finally, go to the requested state
(apply #'goto-state (first form) (rest form))))))
The LispWorks implementation of this macro happens to be very simple.
I'm not saying that this matters, but that it is just a matter of
fact.
It's nice for me to be able to look at this code, and know that the
body of the macro is what handles the connections, and that the macro
expansion will handle the details, and will define the functions I
want:
(start-server :oms)
(stop-server :oms)
If you're used to writing macros that let you program at this level,
and you've come to terms that in a given implementation you'll only be
able to optimize the macroexpansion a certain amount, but you can at
least make things work. At this point, you can close your eyes and
live with implementation differences. Moreover, when new features are
added to your Lisp, you can upgrade your macro definition, and your
application code hopefully doesn't change.
Writing a macro like DEFINE-SERVER lets you achieve portable *and*
readable application code. If you can manage to make your macro
smart, and optimize as much as possible based on the macro usage, then
you end up writing something which itself is portable (provided you've
implemented your macro on all the different back-ends you care
about).
The true test of an implementation for me is:
o which Lisp let's me write the most efficient macro expansion?
o which Lisp let's me implement the macro most easily?
o which Lisp least constrains the possibiliies for the macro?
In this case, I'm more concerned with the first and third questions,
since I don't mind the extra effort all that much.
Just as an aside, Perl has something called NetServer::Generic which
attemps to do kinda what my DEFINE-SERVER macro does. If anyone needs
convincing that Lisp macros offer more expressibility than what
functional libraries tend to offer, then this is it. I got the basic
idea from Perl, but in under 40 LOC was able to write something more
palatable, in my opinion.
dave
On Fri, 15 Jun 2001 07:10:28 -0600, "Wade Humeniuk"
<········@cadvision.com> wrote:
> on time and cannot be bothered to deal with compatibility issues. The Lisp
> vendors got together to produce the ANSI standard, why not an API? There
[...]
> you know the story. Money, Money, Money.
You may have already unknowingly answered your question :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
> * In message <············@news3.cadvision.com>
> * On the subject of "Unification"
> * Sent on Thu, 14 Jun 2001 22:05:13 -0600
> * Honorable "Wade Humeniuk" <········@cadvision.com> writes:
>
> I has become apparent to me that though the APIs from various Lisp
> implementations are similar, they are significantly different enough
> to cause headaches and wasted effort. Many other languages benefit
> from having one standardizing vendor (and library interface) as in the
> case of Perl, Python and Java. Common Lisp can stand to have multiple
> implementations but would benefit greatly from a standardized API.
please see CLOCC/PORT <http://clocc.sf.net>
<http://www.podval.org/~sds/data/port.html>
> I am a relative newbie here but my suggestion is to put the technical
> merits of who has the best application API aside and have the Lisp
> community produce Franz ACL compatibility packages for ...
cool - go and write it!
--
Sam Steingold (http://www.podval.org/~sds)
A year spent in artificial intelligence is enough to make one believe in God.