Modernizing Common Lisp
Dave Roberts
condition system:
http://lists.tunes.org/archives/tunes/2001-February/003058.html
The original message looks like it is over 5 years old. I found the
recommendations to be right on the money.
I bring it up because of the two interesting recent threads titled:
1. "Is anything easier to do in Java than in Lisp?"
2. "The Hyperspec and portability between Common Lisp compilers (long)"
Some of the areas for improvement suggested in this paper are things that I
think are important for modern programming with Lisp. Things like a
standard threads library and a standard network interface library are
critical for Lisp to be able to develop the set of general-purpose
libraries required for rich, modern applications. While many Lisps have
added features in these areas, without standardization the solutions are
fragmented and non-portable.
In short:
1. To help Lisp developers compete with Java and Python developers, the Lisp
camp needs a good set of ready-made library functionality.
2. To develop those sets of libraries, we need to have some amount of
standard functionality that really works across all implementations.
Antonio Leitao's experience trying to write portable CL was interesting, to
say the least, and doesn't bode well for CL. If each CL requires so much
tweaking and no one implementation is dominant, even if many developers
write libraries for various functionality, the libraries will be developed
on many different CL dialects and won't run "out of the box" on any
dialect.
3. Since things like threads and network programming are interesting in
modern programming projects, these areas scream the need for libraries, but
they are also the ones with the most implementation variation since they
are non-standard.
Anyway, I'm just interested in people's reaction here. I fear that the
single implementation versions of Perl and Python, and the tightly
controlled implementations of Java have an advantage over even an "open"
and "standardized" CL unless the larger CL community comes together on some
of these APIs and really implements them.
--
Dave Roberts, ldave-...@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Cameron MacKinnon
> I found this the other day while Googling for some information on the
> condition system:
>
> http://lists.tunes.org/archives/tunes/2001-February/003058.html
>
> The original message looks like it is over 5 years old. I found the
> recommendations to be right on the money.
Wow, that is pretty impressive. The list items have almost all stood the
test of time, save CORBA.
> Some of the areas for improvement suggested in this paper are things that I
> think are important for modern programming with Lisp. Things like a
> standard threads library and a standard network interface library are
> critical for Lisp to be able to develop the set of general-purpose
> libraries required for rich, modern applications. While many Lisps have
> added features in these areas, without standardization the solutions are
> fragmented and non-portable.
I agree completely. I also think it's important to have standards in
these areas because of the negative impression that NOT having them
standardized gives to people evaluating Lisp.
I've written some posts here advocating this. Allow me to summarize the
response I've gotten:
- The CL standard was a long, painful, difficult and expensive birth.
Those involved don't seem keen on repeating the process.
- If you need a cross-platform solution for a particular nonstandard
feature, it's not too tough to write your own compatibility layer (for a
small number of CLs). Quit complaining and code!
It should also be noted that commercial vendors likely don't see a short
term advantage in standardizing such necessary features, as it gives
their customers more opportunity to port to a competitor. Plus it likely
means spending resources rewriting some of their code for no real gain,
and deprecating their customers' pre-standard code.
I don't know how to jump start the process, save by advocating for it.
I've pointed out that the IETF's RFCs and Scheme's SRFIs represent
inexpensive, incremental, workable processes.
It is unfortunate (for our purposes here) that this newsgroup is full of
people who have made Lisp work for them, and unlikely to contain many of
the disaffected, for whom lack of standards in these areas may have been
a deciding factor in turning elsewhere.
Why don't more implementers and users feel the need for further
standardization?
--
Cameron MacKinnon
Toronto, Canada
Wade Humeniuk
>
> It is unfortunate (for our purposes here) that this newsgroup is full of
> people who have made Lisp work for them, and unlikely to contain many of
> the disaffected, for whom lack of standards in these areas may have been
> a deciding factor in turning elsewhere.
>
> Why don't more implementers and users feel the need for further
> standardization?
>
>
Other languages do not have standards for threading, or GUIs or
Networking. They have libraries or single implementations which
are widely used amoungst their users. Why should CL be any
different? Name some language which has any library standard
which is not a single implementation language. Why are you
holding up CL to a different standard?
Wade
Fred Gilham
> Why don't more implementers and users feel the need for further
> standardization?
I think there is something of a disincentive for implementers to back
standardization efforts because it makes it easier for their customers
to switch to other vendors. OTOH, it also makes it easier for the
customers of other vendors to switch to them, so it may be a wash, I
don't know.
In other words standardization leads to commoditization.
There is also another point. Vendors should be customer driven. But
customers usually want features. If my Lisp already has a thread
implementation, an FFI, and a networking library, a vendor is more
likely to address things the implementation doesn't have that
customers are demanding rather than worrying about standardization
efforts. If customers demand standardization that might make a
difference --- the Common Lisp standard grew out of a very large
customer's demand for it. That very large customer eventually cut and
ran after the standard was developed, but that's another issue.
I guess what I'm saying is that Lisp users should not expect vendors
to drive the standardization process. Users have to do it. Vendors
will, of course, play a major role in shaping the form of a standard,
given that they will have to implement it. But users have to say what
they want to standardize, and have to indicate in some compelling way
how badly they want it.
OK, so why don't more users feel the need for further standardization?
Well, I'd argue that satisfied users don't care that much about
standardization. That's because they aren't looking to change
vendors, so they don't care if their programs run on another vendor's
implementation. Customers with a long term view might be more
sensitive to standardization but again it may not be a priority.
The kind of users who care about standardization are usually trying to
run cross-platform. It is apparently more desirable for vendors to
make their implementations run on all leading platforms than to worry
about standardization.
--
Fred Gilham gil...@csl.sri.com
What if thou make us able to make like thee ---
To light with moons, to clothe with greenery,
To hang gold sunsets o'er a rose and purple sea!
-- George MacDonald
Cameron MacKinnon
> Other languages do not have standards for threading, or GUIs or
> Networking. They have libraries or single implementations which
> are widely used amoungst their users. Why should CL be any
> different? Name some language which has any library standard
> which is not a single implementation language. Why are you
> holding up CL to a different standard?
Other languages DO have standards (de facto or de jure) for these things.
From a user's perspective, the difference between
- a language with many implementations, and a standard foo API
- a language with one implementation, with a foo API
- a language with a standard library containing a foo API
is nil. The user can write portable code that builds on the foo API.
Contrast with a language that has multiple implementations, each with a
different foo API.
Do you disagree with Dave Roberts when he says that the lack of
standardized fundamentals is likely holding back development of portable
libraries which build on them? Do you disagree with my added reasons for
standardizing?
Why are you willing to use apparent mediocrity in other computer
languages as an excuse for API fragmentation in CL? Is "just as good as
other languages" what drew you to CL? Is it what you think CL should aim
for?
I'm advocating for expanding the CL standard, or building on it. I've
given some reasons why I think this is a benefit. It is really
immaterial to me whether or not you, or anyone, thinks of that as
"holding up CL to a different standard."
Matthew Danish
> Other languages DO have standards (de facto or de jure) for these things.
You're kidding, right?
Let me try and compile this "standard" BSD socket code on Windows in
Visual Studio ..hmm.. it's C, so it should run _anywhere_ right?
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Cameron MacKinnon
> On Thu, May 06, 2004 at 01:13:54PM -0400, Cameron MacKinnon wrote:
>
>>Other languages DO have standards (de facto or de jure) for these things.
>
>
> You're kidding, right?
>
> Let me try and compile this "standard" BSD socket code on Windows in
> Visual Studio ..hmm.. it's C, so it should run _anywhere_ right?
Oops, did your connection get garbled? Did it appear to you that I
claimed that C has a standard networking API? That ALL other languages
have standardized EVERYTHING?
It is beyond dispute that Microsoft copied the BSD socket API. They just
gratuitously changed it slightly. Blame your vendor.
Wade Humeniuk
>
> Why are you willing to use apparent mediocrity in other computer
> languages as an excuse for API fragmentation in CL? Is "just as good as
> other languages" what drew you to CL? Is it what you think CL should aim
> for?
>
You have not answered my question. Why are you holding up CL to
a different standard (and thus the people around it)?
Your implication is that it is a superior language, thus it
has to have single monolithic authoritative standard libraries.
Sorry, but that is ridicdulous. I am sorry you are disappointed with the
"other" languages and are putting your unrealistic hopes on
CL.
> I'm advocating for expanding the CL standard, or building on it. I've
> given some reasons why I think this is a benefit. It is really
> immaterial to me whether or not you, or anyone, thinks of that as
> "holding up CL to a different standard."
>
Once again you are mistaking your personal disappointment for
reality.
Wade
Cameron MacKinnon
> Cameron MacKinnon wrote:
>
>>
>> Why are you willing to use apparent mediocrity in other computer
>> languages as an excuse for API fragmentation in CL? Is "just as good
>> as other languages" what drew you to CL? Is it what you think CL
>> should aim for?
>>
>
> You have not answered my question. Why are you holding up CL to
> a different standard (and thus the people around it)?
What is this "different standard"? People coding in Java don't have to
worry about the idiosyncrasies of their vendor's network API or threads
API. Java is not a single implementation language. I'm sure you can
think of plenty of similar examples.
CL certainly isn't the only language whose users have cried out for a
single API to address these (and other) things. Other languages have
delivered. So I'm not holding CL to a higher standard than others have
held other languages to.
> Your implication is that it is a superior language, thus it
> has to have single monolithic authoritative standard libraries.
Well, I don't want you to be confused by my subtle implications, so I'll
spell it out. ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL
PURPOSE YET HAS NO STANDARD NETWORK API IS INFERIOR IN THAT RESPECT, AND
INDEED BLIGHTED. Do you disagree?
> Sorry, but that is ridicdulous. I am sorry you are disappointed with the
> "other" languages and are putting your unrealistic hopes on
> CL.
Is there something specific about the CL community that makes my hopes
unrealistic? Because other languages have standardized these things, and
other languages have ongoing standardization processes. Why do YOU hold
CL to a lower standard in this regard?
Will Hartung
"Cameron MacKinnon" <cmack...@clearspot.net> wrote in message
news:wqednVN_Ab3...@golden.net...
> Wade Humeniuk wrote:
> Do you disagree with Dave Roberts when he says that the lack of
> standardized fundamentals is likely holding back development of portable
> libraries which build on them? Do you disagree with my added reasons for
> standardizing?
Yes, I do. I disagree with all of it, and here's why.
The thing holding back the development of ANY library, much less a portable
library, is developers writing them. Period. That's the "problem".
When there is momentum in the development space to produce these libraries,
then following on the coat tails of that momentum is desire to port or
standardize those libraries. People write code and libraries to solve
problems in their environment. If they decide to publish that code, then
someone else may well desire to use and port it. The benefit is that the
person doing the port has only the burden to make the library compatible
with their version, rather than creating the library from scratch. For some
libraries, the porting effort is less than the out and out develop from
scratch effort. For others, it's not so clear.
Common Lisp came together because of the desire of the USERS of the
language. These users were doing enough work, and, paying enough money to
the CL developers, to warrant the effort, time and money that was necessary
to get the parties together, hash out the details (and boy, are there
details), and THEN convert the respective implementations to conform to the
new Standard. It is obvious that the push from this came from the
development community, and then, partially, from the implementation
community. There is value to the implementors to keep customers locked in to
their tools, but at the same time there is value in having a wider consumer
base by having an implementation that works with disparate source sets.
We now have several commercial implementations of CL. What is clear to me
here, is that a VAST majority of CL usage is done "under the radar", used in
custom, industry specific, very specialized software. Software that may well
never leave the company that wrote it. I would like to think that c.l.l is
not a representative set of the CL developers, that the market is actually
larger than what we see here. SOMEONE is paying Franz, Xanalys, Digitool,
Corman and others to keep their doors open and expanding and refining their
implementations. For a "dead" language, we have a lot of vendors.
It is clear to me that these users of CL are not using CL because of its
"vast array of libraries", nor are they (necessarily) using it for its
portability. If they are using it for its portability, then the
implementations conform enough to mean that porting the software is actually
pretty low on their list of problems. When it comes down to it, the
commercial implementations are very similiar on the "bullet point
comparison" test of features, even if they are not absolutely, 100% syntax
compliant. And CL particularly lends itself well to molding and merging and
adapting to where porting from Franz to Xanalys is probably just not a big
deal.
Portability is only important when you want to share vast amounts of source
code, which is something pretty much "unique" to the OSS world, but less
important to the "real world". Simple example: there are MILLIONS of lines
of "BASIC" code written across the planet, and all of them are in any of a
gazillion implementations, and notably "non-portable". How many Visual Basic
clones are there? Running on Linux? Anyone? One of the most popular
languages on the planet and it's ported to ... where?? Nowhere. No place.
zilch. Hell, modern VB isn't hardly source compatible with early versions.
Why is that?
Python, Perl, Ruby, etc are (mostly) source portable because their
respective OWNERs (singular) decided to port them. Java is portable because
that was a niche Sun decided it wanted to fill, and in so doing is created
the entire JVM mechanism to facilitate the problem. Sun also decided that
releasing huge swaths of platforms, specifications, and other TLAs would
help promote Java. In many ways it has, but even then, even code written to
any of these plethora of standards, has problems porting in the Java world,
due to the implementations not conforming or because of "gray areas" in the
implementations.
Save from Sun being VERY proactive on this front of standardizing and
platforming anything they can get their hands on, "standards" come from
demand. Standards come from those using them. Again, in the Java community,
there's a big hubbaloo about JDO (a persistent object specification).
Meanwhile, a large array of developers are running over to Hibernate, as a
de facto peristent object via O/R mapping IMPLEMENTATION. They use it, they
like it, and JDO withers.
We have now defacto implementations and compatability of most of the things
folks cry about with CL, perhaps save a GUI. Through portability libraries
already on the web.
We do not have every CL implementation able to support all of this extra
functionality yet. It's not like CLISP doesn't WANT to be multithreaded,
it's just not happened yet. And you know what? Coming out with ACL Standard
3.0 isn't going to accelerate adding it to CLISP. CLISP is going to change
as the users and implementors want. Just like any of the other implementors.
Lack of standards is not "holding" CL back. It's lack of developers with the
will to solve their problems using the language. Or, for those with the
will, they're simply not "sharing", for whatever reason. There is an
implementation of CL for pretty much any platform that solves all of the
problems developers say they need standardized. All of this is done, its
simply not being used.
At this point, we'll cue the "don't want to pay for CL" threads. Of course,
this has nothing to do with standards either.
It is "trendy" and "hip" to want to solve the worlds problems with source
code, rather than just solving your own problems and perchance publishing
the code so others can use or port it. One can argue that this "desire to be
portable" is what is holding back CL, but I really don't think that's the
issue. It's more to do just with how CL is "simply different" than
everything else. The reasons that it is unpopular are the same reasons it
has such passions around it. New standards won't hurt, but, frankly, they
won't help either.
Regards,
Will Hartung
(wi...@msoft.com)
Wade Humeniuk
>
> Well, I don't want you to be confused by my subtle implications, so I'll
> spell it out. ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL
> PURPOSE YET HAS NO STANDARD NETWORK API IS INFERIOR IN THAT RESPECT, AND
> INDEED BLIGHTED. Do you disagree?
>
Yes, I disagree. CL is general puprose. Each implementation has
a standard api. CL applications are quite capable of networking.
The facts are that CL apps can do all these things and there exist
libraries that provide cross implementation interfaces. CL has
all that you call a standard network api. Maybe you like to try
another example? It is pretty obvious that you have not
coded much with CL or you would know all that. It is only your
ignorant whining that asserts that which is not supported by the
facts.
>> Sorry, but that is ridicdulous. I am sorry you are disappointed with the
>> "other" languages and are putting your unrealistic hopes on
>> CL.
>
>
> Is there something specific about the CL community that makes my hopes
> unrealistic? Because other languages have standardized these things, and
> other languages have ongoing standardization processes. Why do YOU hold
> CL to a lower standard in this regard?
>
CL is just as standardized as any other language out there. Specific
implementations have their own standard interfaces. It is no different
for any other language. You pull up Java as example. Well the other
implementors of Java just let Sun do the design for them. There is
really only one implementation, though of course Java has more than
one standard interface for GUIs, web services, etc, etc, etc.
Wade
Erann Gat
Wade Humeniuk <whum...@telus.delete.net> wrote:
> > I'm advocating for expanding the CL standard, or building on it. I've
> > given some reasons why I think this is a benefit. It is really
> > immaterial to me whether or not you, or anyone, thinks of that as
> > "holding up CL to a different standard."
> >
>
> Once again you are mistaking your personal disappointment for
> reality.
If the person speaking is a potential customer and you are a supplier
then their personal disappointment *is* your reality. This is a fact
that the Lisp community would do well to learn better IMHO.
E.
niko...@random-state.net
turned out to be both. Oh well.
Will Hartung <wi...@msoft.com> wrote:
>> Do you disagree with Dave Roberts when he says that the lack of
>> standardized fundamentals is likely holding back development of portable
>> libraries which build on them? Do you disagree with my added reasons for
>> standardizing?
> Yes, I do. I disagree with all of it, and here's why.
> The thing holding back the development of ANY library, much less a portable
> library, is developers writing them. Period. That's the "problem".
Hear, hear!
> with their version, rather than creating the library from scratch. For some
> libraries, the porting effort is less than the out and out develop from
> scratch effort. For others, it's not so clear.
And sometimes the first library/application to hit the
market/cliki/common-lisp.net has architecture problems, or the original
author(s) may be unreceptive or unavailable. Sometime from the scratch
pays off, sometimes it doesn't. Though cookie.
(with-rant
"What has never paid off and _never_ will is bitching about the N
incomplete libraries for X, and how the people working on those really
should get their act together and coalesce their efforts. Sometimes it
happens due to the developers themselves discovering synergetic benefits,
but just as often it doesn't -- but I've never heard of it once happening
because someone said ``you people are silly''.")
> We now have several commercial implementations of CL. What is clear to me
> here, is that a VAST majority of CL usage is done "under the radar", used in
> custom, industry specific, very specialized software. Software that may well
> never leave the company that wrote it. I would like to think that c.l.l is
> not a representative set of the CL developers, that the market is actually
> larger than what we see here. SOMEONE is paying Franz, Xanalys, Digitool,
> Corman and others to keep their doors open and expanding and refining their
> implementations. For a "dead" language, we have a lot of vendors.
Very true. There is plenty of activity outside cll on not just the
commercial fronts, but on the open source sector as well. Hands up, how
many here consider cll more of a "prime flaming ground" then a place to
have productive discussions?
/me raises hand
This doesn't preclude valuable interchanges here or make cll meaningless,
but it does tend to colour things a bit.
> Python, Perl, Ruby, etc are (mostly) source portable because their
> respective OWNERs (singular) decided to port them.
And even they have a fair share of problems: source portability between
different versions of those languages (including Java) is mostly a matter
of luck (an in not happening to use the features that change in the next
version), and there are platform differences as well. What's more, Python
and Ruby are neither single implementation any more: there's JRuby and
JPython, neither of which is 100% compatible with the "official"
implementation.
> We have now defacto implementations and compatibility of most of the things
> folks cry about with CL, perhaps save a GUI. Through portability libraries
> already on the web.
Here I beg to disagree a bit. Some of the portability libraries aren't
really -- for example CLOCC-PORT, which is pretty happy-go-lucky when it
comes to plastering over differences of various implementations. There's
still ground to cover there.
But -- what has been said about the factual ease of porting and writing
application specific abstractions remains very true. It's easy. And when
(not if) it happens in sufficient degree more solid standards (de facto or
otherwise) are bound to emerge. Whether this take 6 months or 12 years is
anybody's guess. ;-)
> functionality yet. It's not like CLISP doesn't WANT to be multithreaded,
> it's just not happened yet. And you know what? Coming out with ACL Standard
> 3.0 isn't going to accelerate adding it to CLISP. CLISP is going to change
> as the users and implementors want. Just like any of the other implementors.
^
/and can, and have tackeled other
goals of higher priority/
> Lack of standards is not "holding" CL back. It's lack of developers with the
> will to solve their problems using the language. Or, for those with the
Happily the number of developers seems to be on the upswing, though. If I
had one CL wish from a djinni, I'd be hard pressed to choose between:
* Giving Tim Bradshaw a gun and home addresses of all cll posters.
* Having the standard amended to highest perfection ever seen in the
annals of computing, including all the gazillion "must have" libraries.
* Having a high-quality open source Lisp ported to Windows so that people
would have to think of new things to bitch about.
They would all accomplish the same -- five minutes of silence. ;-) Then
someone would appear with a new reason why he can't use CL, or why CL
isn't more popular.
Cheers,
-- Nikodemus
Pete Kirkham
> 1. To help Lisp developers compete with Java and Python developers, the Lisp
> camp needs a good set of ready-made library functionality.
date when MS launches longhorn. There is effort with open office, but
low level libraries were last decade's trick, not this one's. A Lisp for
Longhorn, that gives users the same flexibility that the embedded lisp
for emacs does would be close to a killer.
Instead, provide compatibility with the existing libraries, either Java
or .net. If you want an XML parser, just use one. If you think that lisp
compilers are more efficient than the .net ones, put your knowledge into
mono.
You could also sell lisp as a player on a common platform- it may be we
end up seeing people hired as .net programmers, not C# or Visual Basic.
A lisp for byte code VMs could make 'lisp jobs' more easily come by.
> 2. To develop those sets of libraries, we need to have some amount of
> standard functionality that really works across all implementations.
A CL that runs on Java or .net (particularly the latter, but either
virtual machines would require similar work) would drastically increase
usage. Linj and armedbear-lisp are part way to getting CL in Java
already. What I would really like is a MOP implementation compatible
with UML2 with a lisp based metalanguage for patterns and transforms,
and KIF/Concept graphs for domain knowledge, allowing one system to span
all the levels from domain to implementation in the same environment,
with X3D, SVG and XForms (using a s-expression syntax) to describe the
UI, ASN.1 for IO, and a relation engine that does what XSLT does but
with context. Build the API on the best of what's available in the open,
and implement it by calling the existing codebases.
The problem is that this requires a disjunction with the current
implementations; I'm not sure whether the CL standard needs changing, or
if the library APIs can be specified at a sufficient level that most of
them can be implemented by calling out to standard services. Certainly
basing them on open non-language specific standards, rather than CL
specific ones (however open) seems a better bet for uptake. I'd bet that
more programmers know HTML forms and SVG than CLIM, so APIs based on a
minimum learning curve can help crossover. UML and code generation are
fairly big, a platform that seamlessly integrates the model and the code
could be a big win. Having a language based on an ANSI standard, and
libraries based wherever possible on standards or commonly used
specifications would minimise FUD of any language- you'd know that all
the bits worked already.
> Anyway, I'm just interested in people's reaction here. I fear that the
> single implementation versions of Perl and Python, and the tightly
> controlled implementations of Java have an advantage over even an "open"
> and "standardized" CL unless the larger CL community comes together on some
> of these APIs and really implements them.
I don't think the languages are what will matter in the longer term, nor
the libraries that can be maintained by small, language specific, open
source communities. Either you're playing with the system services of
the majority of systems, or you won't be in the game at all. Someone
will either come up with some language for the big byte code platforms
that steals all of CL's pearls, or the CLers will have to play the game.
Pete
Erann Gat
"Will Hartung" <wi...@msoft.com> wrote:
> The thing holding back the development of ANY library, much less a portable
> library, is developers writing them. Period. That's the "problem".
That may be, but that begs the question of why people don't write them.
A plausible theory is that they lack of standardization mitigates
against one of the main incentives for people to write them, namely, the
possibility that the code will be widely deployed.
> I would like to think that c.l.l is
> not a representative set of the CL developers, that the market is actually
> larger than what we see here. SOMEONE is paying Franz, Xanalys, Digitool,
> Corman and others to keep their doors open and expanding and refining their
> implementations. For a "dead" language, we have a lot of vendors.
The financial viability of Digitool, Corman, and whatever "others" you
may be referring to is in considerable doubt.
> Portability is only important when you want to share vast amounts of source
> code, which is something pretty much "unique" to the OSS world, but less
> important to the "real world". Simple example: there are MILLIONS of lines
> of "BASIC" code written across the planet, and all of them are in any of a
> gazillion implementations, and notably "non-portable". How many Visual Basic
> clones are there? Running on Linux? Anyone? One of the most popular
> languages on the planet and it's ported to ... where?? Nowhere. No place.
> zilch. Hell, modern VB isn't hardly source compatible with early versions.
> Why is that?
Anything sponsored by Microsoft is subject to significantly different
market dynamics than anything that is not sponsored by Microsoft.
Accordingly, VB is not a good analogy for Common Lisp. If MS supported
Lisp we would not be having this conversation.
> We do not have every CL implementation able to support all of this extra
> functionality yet. It's not like CLISP doesn't WANT to be multithreaded,
> it's just not happened yet. And you know what? Coming out with ACL Standard
> 3.0 isn't going to accelerate adding it to CLISP. CLISP is going to change
> as the users and implementors want. Just like any of the other implementors.
Maybe, maybe not. It is possible that among the many factors that
individual contributors take into account when they decide how to spend
their time is standards compliance. It's possible that somewhere out
there is someone poised on the cusp of diving into the work of adding
threads to CLisp, but they are being held back by the fact that there is
no CL threads standard, which means that they have to do the extra work
of designing their own API, or selecting from among the several
proprietary designs floating around out there.
> Lack of standards is not "holding" CL back. It's lack of developers with the
> will to solve their problems using the language. Or, for those with the
> will, they're simply not "sharing", for whatever reason.
And that "whatever reason" could very well be standards. I, for
example, wrote some lightweight database code (motivated by the fact
that none of the shared code out there worked when I tried it), but I
haven't bothered to share it because it's MCL-specific, and so I have
judged the potential audience too small to be worth the bother of making
the code suitable for distribution.
> At this point, we'll cue the "don't want to pay for CL" threads. Of course,
> this has nothing to do with standards either.
Of course it does. The Lisp code I run on my Mac won't work on any Lisp
I can get for my Linux machine -- whether or not I pay for it. The
reason I don't buy a Lisp for Linux is not because I'm unwilling to pay
for Lisp (I pay for the Lisp I run on my Mac) but because paying for it
won't do me any good. And the reason it won't do me any good is
directly related to the lack of standardization for functionality that
is basic for modern computing.
E.
Will Hartung
> worry about the idiosyncrasies of their vendor's network API or threads
> API. Java is not a single implementation language. I'm sure you can
> think of plenty of similar examples.
No, they only have to worry about the idiosyncracies of their network or
threads IMPLEMENTATION. While a "standard" API is all peachy and wonderful,
there's nothing to stop someone from having crappy implementations
underneath that shroud of "compatability". Java has had a long and sordid
history with regards to threads (who's API has, in fact, changed in the
past).
> Well, I don't want you to be confused by my subtle implications, so I'll
> spell it out. ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL
> PURPOSE YET HAS NO STANDARD NETWORK API IS INFERIOR IN THAT RESPECT, AND
> INDEED BLIGHTED. Do you disagree?
Just to be clear that you consider C, C++, FORTRAN, Ada, Delphi, and, of
course, probably the most recently standardized of languages, arguably the
most "modern" mainstream language, C#, on those same grounds. None of those
lanaguages have a "standard" network API. Popular ones? De Facto ones? Sure.
Oh, wait, so does CL!
In fact, you can have a compliant JVM that has no support for networking as
well. OMG! I see your Standard and raise you an Implementation.
> Is there something specific about the CL community that makes my hopes
> unrealistic? Because other languages have standardized these things, and
> other languages have ongoing standardization processes. Why do YOU hold
> CL to a lower standard in this regard?
We don't. That's the point. We know the difference between a Language and an
Implementation. We know that Common Lisp can be used for a HUGE domain of
problems, many of which don't even come near these APIs you're fixated on.
We know that Common Lisp can be tuned, bent, hammered, and tweaked to
support domains in areas that we haven't even considered yet. We know that
when They(tm) started the Standardization process, They(tm) actually took
into consideration not simply the language, but the implementations
available, the trials and tribulations of implementing CL, the hows and whys
it could be implemented, and the variety of architectures it could be
implemented upon. There is quite a bit of thought in the CL Standard, things
that implementors of todays languages do not even think about.
If anything, we hold CL to a higher standard to let us concoct any API that
suits us to facilitate the task at hand.
Regards,
Will Hartung
(wi...@msoft.com)
Will Hartung
"Erann Gat" <gNOS...@flownet.com> wrote in message
news:gNOSPAMat-0478A...@nntp1.jpl.nasa.gov...
> In article <2fvjemF...@uni-berlin.de>,
> "Will Hartung" <wi...@msoft.com> wrote:
>
> > Lack of standards is not "holding" CL back. It's lack of developers with
the
> > will to solve their problems using the language. Or, for those with the
> > will, they're simply not "sharing", for whatever reason.
>
> And that "whatever reason" could very well be standards. I, for
> example, wrote some lightweight database code (motivated by the fact
> that none of the shared code out there worked when I tried it), but I
> haven't bothered to share it because it's MCL-specific, and so I have
> judged the potential audience too small to be worth the bother of making
> the code suitable for distribution.
So, you think that the necessity for someone to port the implementation
specific bits of your code to their platform will outweigh any benefit your
portable code will offer them? That porting will be harder for them than
writing what they need from scratch?
> > At this point, we'll cue the "don't want to pay for CL" threads. Of
course,
> > this has nothing to do with standards either.
>
> Of course it does. The Lisp code I run on my Mac won't work on any Lisp
> I can get for my Linux machine -- whether or not I pay for it. The
> reason I don't buy a Lisp for Linux is not because I'm unwilling to pay
> for Lisp (I pay for the Lisp I run on my Mac) but because paying for it
> won't do me any good. And the reason it won't do me any good is
> directly related to the lack of standardization for functionality that
> is basic for modern computing.
The strange thing I see here is that you're willing to throw the baby out
with the bathwater. Perhaps the GUI is the One Thing keeping you on MCL.
GUIs are a mess in any cross platform project, in any language. Java's been
struggling with this since the get go, and they're working on their 3rd
version now. (AWT, Swing, SWT). So, I'm going to punt on that point, just
toss it aside. It's a deep, dark, black hole, and we all know that.
Also, I'm ignorant of how MCL deals with networking. Maybe they do some
wacky stuff above socket, listen, accept, connect, read/write and select.
But it's hard to fathom what. Most of the Lisp socket implementations seem
to expose that high level aspect of the API. Most don't go down into the
deep nuances of TCP and IP that the raw, low level APIs of the Berkley
Sockets, but most applications don't need that level of detail. Maybe your's
does.
Most of the "threading" implementations seem very similar to the CLIM model
as well, but again, I don't know anything about MCL. Of course some of those
implementations differ as to whether they use native threads or not. I think
even Franz's implementations vary across platforms, tho the API is the same.
But, basically, you're saying that the level of platform dependence of your
Lisp code is so ingrained, that it's not even worth pursuing to port it to
your Linux machine. Best throw it all out and start new on the Linux box.
That it is not worth implementing the MCL specific calls on your Linux Lisp
to port your code. It is simply too difficult, and the code isn't worth it.
Does it affect casual porting of the code? Sure it does. But even conforming
implementations have issues porting code, even if they implement the same
APIs. Look at the difficulty of porting Unix apps to Mac OS X. Porting those
apps to Mac OS 9-- were Just Too Hard. But now that there is "more unix",
applications and code can more easily be bent to work on OS X, so porting is
worthwhile vs tossing it all away and starting anew.
But if you were willing to post your code, perhaps someone else would find
the value of the code worth the effort to actually port it, then again,
maybe it simply relies too much on the MCL implementation.
We we're mostly talking sockets and threads here I thought.
Regards,
Will Hartung
(wi...@msoft.com)
niko...@random-state.net
> That may be, but that begs the question of why people don't write them.
> A plausible theory is that they lack of standardization mitigates
> against one of the main incentives for people to write them, namely, the
> possibility that the code will be widely deployed.
What do you mean "why people don't write them"? If you said "why there
aren't yet hundreds of them" I might agree, but the number of existing
libraries seems is growing at an accelerating rate-- even if not all of
them are as high quality as we'd like.
The quality issue is a non-issue, since as far as I know the ration
between bull and sterling libraries and applications is relatively
constant across languages.
> their time is standards compliance. It's possible that somewhere out
> there is someone poised on the cusp of diving into the work of adding
> threads to CLisp, but they are being held back by the fact that there is
> no CL threads standard, which means that they have to do the extra work
> of designing their own API, or selecting from among the several
> proprietary designs floating around out there.
I'm not a mind-reader, nor do I know if someone is on the cusp of adding
threads to Clisp, but I'm willing to bet that anyone willing to dive in to
that kind of work will not be held back by the lack of a standard. Really.
> And that "whatever reason" could very well be standards. I, for
> example, wrote some lightweight database code (motivated by the fact
> that none of the shared code out there worked when I tried it), but I
> haven't bothered to share it because it's MCL-specific, and so I have
> judged the potential audience too small to be worth the bother of making
> the code suitable for distribution.
Two things I don't understand here:
1) Bother of making the code suitable for distribution.
As long as you don't claim anything it isn't, the bother is minimal. Tar
up your source tree and put it up on your website with a note saying:
"Lightweight DB interface for MCL. This is just a tarball of my source
tree, not a fancy drop-in package: no support, no documentation, includes
hardcoded paths, etc. Patches welcome."
If you want to do more, fine, but I for one really don't follow the logic
that doesn't do even the minimum because the maximum is too hard.
2) Apparent willingness to share, but not bothering because the potential
audience seems too small (due to portability in this case, but the
symptom is more general).
How many people would it have to be? Unless you are looking for financial
compensation basing release-or-not decisions of existing code on the
probable number of users is a bit odd.
I could understand reasons like:
"the code is so shoddy that I'm too embarrassed to release it"
"I just don't feel like it"
"nyah, nyah, nyaaah!"
Maybe I'm just missing something obvious here.
> Of course it does. The Lisp code I run on my Mac won't work on any Lisp
> I can get for my Linux machine -- whether or not I pay for it. The
> reason I don't buy a Lisp for Linux is not because I'm unwilling to pay
> for Lisp (I pay for the Lisp I run on my Mac) but because paying for it
> won't do me any good. And the reason it won't do me any good is
> directly related to the lack of standardization for functionality that
> is basic for modern computing.
*boggle*
What proportion of your MCL code is MCL specific? And to what degree? (As
in, do you dip into internals, or is it just unportable vendor
APIs?) Since I suspect the latter, have you really looked at the issue to
see how much work it would be to wrap your needs in separate layer, or use
one of the existing ones?
Why are you willing to pay for Lisp on Mac but not elsewhere? You could
just as well pay for it on both and use an implementation that is ported
to multiple platforms.
If you're not willing to pay for Lisp, why not use a free implementation
that runs on multiple platforms?
Ok, granted, if you need threads then there are currently no free
implementations with threads on both Mac and Linux, but McCLIM still seems
to manage threading fine on both...
Cheers,
-- Nikodemus
Rob Warnock
+---------------
| Anything sponsored by Microsoft is subject to significantly different
| market dynamics than anything that is not sponsored by Microsoft.
| Accordingly, VB is not a good analogy for Common Lisp.
| If MS supported Lisp we would not be having this conversation.
True. Instead, we would be having *much* more anguished conversations
than this one (probably about how Microsoft-proprietary extensions were
destroying the Common Lisp standard)... ;-} ;-}
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Antony Sequeira
>
> What is this "different standard"? People coding in Java don't have to
> worry about the idiosyncrasies of their vendor's network API or threads
> API. Java is not a single implementation language.
I am new to CL and trying to learn it. I hope it never gets threads as
*standard*, so that every implementation is forced to implement thread
support.
Why should I assume "multiple independent (by default) execution
contexts with a shared heap" runtime model best fits all application
domains ?
On the other hand I'd love to have an abstraction over things like
/dev/poll , select, kqueue and whatever Win32 has (I/O completion
ports?) as some library for CL.
Also, Java Threads or n/w API syntactically may not change across
platforms, but I don't know if it works the same. I think people do
have to "worry about the idiosyncrasies of their vendor's network API or
threads API" (this is just a guess on my part).
Also the standard Java (whatever that means in Java since it changes)
n/w api was blocking only. They introduced non-blocking i/o in 1.4 version.
See http://java.sun.com/developer/technicalArticles/releases/nio/
If standard thread support is such a good idea, why the need for
non-blocking I/O ?
I doubt very much the performance characteristics for such API is
comparable across platforms. Performance is an important part of the
semantics for many apps.
Once I use non-blocking, I am into event model programming, the
simplicity of sequential model is lost. I'd rather have either the
simple non-threaded with blocking I/O sequential model, or the
non-threaded event model with non-blocking I/O (when performance is
needed) where performance is gained at some cost to complexity . Having
both threaded blocking sequential , and the non-blocking I/O event model
in one app is complexity beyond what I want to have.
In my current job situation with Java I am stuck with threads, whether I
like it or not, and hence forced into the worst case runtime model (from
complexity POV) since performance is an issue. I am talking about
performance in the face of managing lots of concurrent requests, not
number crunching necessarily.
Threads introduced in a pervasive fashion (as in Java) affects the
available runtime models. I understand CL is multi paradigm from a code
organization POV (object oriented, functional, declarative, imperative)
I would like it to be multi-paradigm from the runtime model POV too.
>ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL PURPOSE YET HAS NO
>STANDARD NETWORK API IS INFERIOR IN THAT RESPECT, AND INDEED BLIGHTED.
>Do you disagree?
I agree, but I almost missed the "IN THAT RESPECT" :)
I am not saying that having a "standard" n/w API is a bad idea. In any
large enough app, the app logic work will dwarf any time spent on
developing n/w access code. Once you develop it, you re-use it. It
definitely is a marketing issue though (for CL that is).
This post is for the purpose of getting feedback on thoughts I have
developed. This was just an opportunity to voice my thoughts.
I am still working on asking a question on cll. Just beginning to
understand OnLisp on my second iteration. Questions soon :)
Thanks,
-Antony
niko...@random-state.net
> spell it out. ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL
> PURPOSE YET HAS NO STANDARD NETWORK API IS INFERIOR IN THAT RESPECT, AND
> INDEED BLIGHTED. Do you disagree?
I disagree.
Name the languages with this standardized networking API please. I don't
know a single one -- oh, there are single implementations languages with
single networking API, but that is wildly different from having a
standardized one: you never know when it's going to change. And you don't
know it works the same on different platforms untill you try -- and more
often then not discover that the level of standardization is rather
vacuous.
Sure, I would not mind having one, but it's definitely not too close to
the top of my personal wish-list, standards or otherwise.
> unrealistic? Because other languages have standardized these things, and
> other languages have ongoing standardization processes. Why do YOU hold
I'm obviously not getting out enough. Once again: what are the languages
with these ongoing standardization processes for the things you ask for?
And don't say Java, 'cos there's nothing standard about Java except the
trademark.
Anyways, to break the tedium, here's a thought:
Getting implementors to agree on a common API for XYZ is hard, especially
when they all already have their own competing ones.
What should be a lot easier for them to agree on would be the set of
features a given API should provide -- you could even split this
into "basic" and "extended" features.
This would give people worrying about portability some reassurance, since
they could rest easy in the knowledge that the features they use are
portable, even if the interfaces may differ.
It would also faciliate writing of portable interfaces, since a modicum
of common ground would be more or less guaranteed,
It might also ease future standardization of the actual API, as the
common feature set might in practical terms translate into convergence.
Just an idle thought,
-- Nikodemus
Martin Elster
> The Lisp code I run on my Mac won't work on any Lisp I can get for
> my Linux machine -- whether or not I pay for it.
If you haven't already, you might want to look at the Port package
from CLOCC [1]. I've found it very helpful, and I am a bit surprised
it doesn't get more notice during these discussions of "standards" for
CL. For me, instead of learning the particular network/thread API's
for Allegro, I could just learn the general Port interface, and my
skills and code are more or less transferable to other CL
implementations on other platforms. Very nice.
I admit I haven't tested it much, but the (mostly networking) code I
have tested has worked fine on SBCL, CMUCL, and ACL on Linux/x86. From
the code it looks like it should work on other
implementations/platforms as well.
I understand the CLOCC code is LGPL, so it might not be suitable for
all purposes, but if you want to publish open-source LGPL libraries
this is just the thing.
BTW: If you are thinking publishing code, I for one would be very
interested in seeing the code for your "locales", as presented on ILC
2003. They look like very interesting, and would be fun to experiment
with.
(hint hint :-)
martin
1. http://clocc.sourceforge.net/ - "This package provides a
platform-independent interface to various features absent from the
ANSI Common Lisp standard, such as sockets, shell, Gray streams
etc.", from the README.
adam connor
>Anyway, I'm just interested in people's reaction here. I fear that the
>single implementation versions of Perl and Python, and the tightly
>controlled implementations of Java have an advantage over even an "open"
>and "standardized" CL unless the larger CL community comes together on some
>of these APIs and really implements them.
I share that worry, although it might be a point for Arc, if and when
it is ever released. Standards are good but nothing is more standard
that a single-sourced, widely ported language.
adam connor
>Does it affect casual porting of the code? Sure it does. But even conforming
>implementations have issues porting code, even if they implement the same
>APIs. Look at the difficulty of porting Unix apps to Mac OS X. Porting those
>apps to Mac OS 9-- were Just Too Hard. But now that there is "more unix",
>applications and code can more easily be bent to work on OS X, so porting is
>worthwhile vs tossing it all away and starting anew.
I primarily write Java code for a living, mostly for web applications
and associated tools. I routinely write code on the PC and port it to
HP-UX or Solaris. We have also written some code that was ported to
Mac OS. Porting Java is usually very, very easy. This has a huge
effect on the number of libraries and tools for Java; most of them
work everywhere.
Yes, Java threads can behave differently on different OSes. And there
can be other occasional quirks; the implementations are not perfect.
But in daily practice, you can usually write on one OS and deploy to
another with only a small amount of thought on making it portable.
It would be great if Lisp had more standard libraries for things like
networking.
Erann Gat
niko...@random-state.net wrote:
> > And that "whatever reason" could very well be standards. I, for
> > example, wrote some lightweight database code (motivated by the fact
> > that none of the shared code out there worked when I tried it), but I
> > haven't bothered to share it because it's MCL-specific, and so I have
> > judged the potential audience too small to be worth the bother of making
> > the code suitable for distribution.
>
> Two things I don't understand here:
>
> 1) Bother of making the code suitable for distribution.
>
> As long as you don't claim anything it isn't, the bother is minimal. Tar
> up your source tree and put it up on your website with a note saying:
> "Lightweight DB interface for MCL. This is just a tarball of my source
> tree, not a fancy drop-in package: no support, no documentation, includes
> hardcoded paths, etc. Patches welcome."
That assumes that I am willing to give my code away for free. If I
were, for example, sympathetic to Kent Pitman's arguments against giving
code away for free then making code suitable for distribution would not
be nearly as simple as that.
But since I did bring it up, I've put the code at
http://www.flownet.com/gat/lisp along with some other stuff. Have a
look and see for yourself if you think it's useful in its present state.
> 2) Apparent willingness to share, but not bothering because the potential
> audience seems too small (due to portability in this case, but the
> symptom is more general).
>
> How many people would it have to be?
Forty two.
> Unless you are looking for financial
> compensation basing release-or-not decisions of existing code on the
> probable number of users is a bit odd.
Not at all. Who knows what motivates people to do what they do? Maybe
I'm doing this for an ego trip.
> I could understand reasons like:
>
> "the code is so shoddy that I'm too embarrassed to release it"
That's a significant factor, actually. I'm not really a programmer
despite the fact that I occasionally write some code.
> "I just don't feel like it"
There's some of that too, frankly. I'm getting old, and life is short.
> > Of course it does. The Lisp code I run on my Mac won't work on any Lisp
> > I can get for my Linux machine -- whether or not I pay for it. The
> > reason I don't buy a Lisp for Linux is not because I'm unwilling to pay
> > for Lisp (I pay for the Lisp I run on my Mac) but because paying for it
> > won't do me any good. And the reason it won't do me any good is
> > directly related to the lack of standardization for functionality that
> > is basic for modern computing.
>
> *boggle*
>
> What proportion of your MCL code is MCL specific?
Well, it depends on which code you're talking about. I have recently
discovered the miraculous power of calling OS X framework code from MCL,
so lately I've been writing nothing but MCL-specific code.
Truthfully, I don't know how many MCL dependencies are built in to my
code because I hardly ever try to run it under anything else.
> Why are you willing to pay for Lisp on Mac but not elsewhere?
Because I do all my development on a Mac. Because I've been using MCL
since it was Coral Common Lisp. Because I like Fred better than I like
Emacs. Because I have to pay for it out of my own pocket and LispWorks
and ACL do not seem to me to be good value for the money by comparison.
> You could
> just as well pay for it on both and use an implementation that is ported
> to multiple platforms.
Yes, I suppose I could. But that is beside the point. I am not
claiming that the lack of standards leads to insurmountable problems,
only that they lead to loss of customers.
> If you're not willing to pay for Lisp, why not use a free implementation
> that runs on multiple platforms?
Because I like MCL, and because I believe in paying for things when they
provide good value for the money.
> Ok, granted, if you need threads
I wonder where you think CL's market niche could possibly be if you can
seriously pose such a hypothetical. In this day and age that seems to
me tantamount to saying, "OK, granted, if you need floating point
math..."
E.
Erann Gat
Martin Elster <mel...@turing.uio.no> wrote:
> BTW: If you are thinking publishing code, I for one would be very
> interested in seeing the code for your "locales", as presented on ILC
> 2003. They look like very interesting, and would be fun to experiment
> with.
>
> (hint hint :-)
See http://www.flownet.com/gat/lisp
E.
Erann Gat
"Will Hartung" <wi...@msoft.com> wrote:
> "Erann Gat" <gNOS...@flownet.com> wrote in message
> news:gNOSPAMat-0478A...@nntp1.jpl.nasa.gov...
> > In article <2fvjemF...@uni-berlin.de>,
> > "Will Hartung" <wi...@msoft.com> wrote:
> >
> > > Lack of standards is not "holding" CL back. It's lack of developers with
> the
> > > will to solve their problems using the language. Or, for those with the
> > > will, they're simply not "sharing", for whatever reason.
> >
> > And that "whatever reason" could very well be standards. I, for
> > example, wrote some lightweight database code (motivated by the fact
> > that none of the shared code out there worked when I tried it), but I
> > haven't bothered to share it because it's MCL-specific, and so I have
> > judged the potential audience too small to be worth the bother of making
> > the code suitable for distribution.
>
> So, you think that the necessity for someone to port the implementation
> specific bits of your code to their platform will outweigh any benefit your
> portable code will offer them? That porting will be harder for them than
> writing what they need from scratch?
No. I'm saying that the lack of standards is putting a certain amount
of drag on the collective Lisp economy.
> > > At this point, we'll cue the "don't want to pay for CL" threads. Of
> course,
> > > this has nothing to do with standards either.
> >
> > Of course it does. The Lisp code I run on my Mac won't work on any Lisp
> > I can get for my Linux machine -- whether or not I pay for it. The
> > reason I don't buy a Lisp for Linux is not because I'm unwilling to pay
> > for Lisp (I pay for the Lisp I run on my Mac) but because paying for it
> > won't do me any good. And the reason it won't do me any good is
> > directly related to the lack of standardization for functionality that
> > is basic for modern computing.
>
> The strange thing I see here is that you're willing to throw the baby out
> with the bathwater. Perhaps the GUI is the One Thing keeping you on MCL.
Actually, the main thing keeping me on MCL is Fred, but that has nothing
to do with anything. Different people use different implementations for
different reasons.
> Also, I'm ignorant of how MCL deals with networking.
Badly, mostly as a result of legacy cruft from the bad old days of OS<10.
Fortunately, there turns out to be an easy workaround on OS X (though
nobody knows it ;-). See http://www.flownet.com/gat/fstream.lisp
> Maybe they do some
> wacky stuff above socket, listen, accept, connect, read/write and select.
> But it's hard to fathom what. Most of the Lisp socket implementations seem
> to expose that high level aspect of the API. Most don't go down into the
> deep nuances of TCP and IP that the raw, low level APIs of the Berkley
> Sockets, but most applications don't need that level of detail. Maybe your's
> does.
Nope. But even as simple a thing as opening a client TCP socket is not
portable across Lisp implementations.
> But, basically, you're saying that the level of platform dependence of your
> Lisp code is so ingrained, that it's not even worth pursuing to port it to
> your Linux machine. Best throw it all out and start new on the Linux box.
> That it is not worth implementing the MCL specific calls on your Linux Lisp
> to port your code. It is simply too difficult, and the code isn't worth it.
No, I didn't say that.
What I'm saying is that if someone wants to contribute portable Lisp
code it's a lot harder than it would be if these things were
standardized. That's all.
> But if you were willing to post your code, perhaps someone else would find
> the value of the code worth the effort to actually port it, then again,
> maybe it simply relies too much on the MCL implementation.
http://www.flownet.com/gat/lisp
> We we're mostly talking sockets and threads here I thought.
Sockets. Threads. Database. Regular expressions. These are the Big
Four that Lisp is lacking IMO.
But what we really need is something comparable to what you can find at
http://www.python.org/doc/current/modindex.html
E.
Peter Seibel
> Sockets. Threads. Database. Regular expressions. These are the Big
> Four that Lisp is lacking IMO.
So I'd suggest that Edi's CL-PPCRE knocks off regexps. I don't know of
any reason *not* to use it. Fast, portable, and mind-share compatible
with Perl (as much as is possible or desirable.
He seems to have done the work of making sure it runs on just about
every available CL implementation though he hasn't--according to his
web page--been able to personally test every new version he's written
on all the impls. Presumably he would be happy to get bug reports from
someone who actually uses a particular implementation.
In other words, unless I'm missing something, (and IMHO) CL-PPCRE
should *already* be the defacto standard for regexps in Lisp. But
clearly it has not achieved that status since we're having this
conversation. So the question--for folks who think some defacto
standards would be good--is how to move forward.
One possibility is for the advocates of "mo' standards, mo' betta" to
do some legwork and see if they can convince the various
vendors--commercial and open source--to simply include some stable
version of cl-ppcre in their implementations. Then it becomes a
defacto standard. (Obviously the commercial vendors who have already
written their own regexp libraries might not be as motivated to do
this. But it doesn't cost them a lot--some QA and some documentation
on something that's already pretty well tested and documented as far
as I can tell. And if by so doing they make Common Lisp as a whole
more attractive that has to help their business.)
Or maybe the folks working on Lisp In A Box will include it in the box
so all the newbies they attract will discover that Lisp has regexps
"out of the box".
Or if all that seems like too much work, if everytime someone comes to
c.l.l. and asks, "How do I do regexps in Common Lisp?" pipe up with
"CL-PPCRE which is available at <http://www.weitz.de/cl-ppcre/>"
instead of "Well ... it depends."
-Peter
P.S. If there is some problem with CL-PPCRE that I'm not aware of that
makes it unsuitable for promotion to defacto standard regexp library
I'd be interested to know what it is. I have to belive that it's at
least a very good starting point. And the license, IIRC, is ammenable
to inclusion in both comercial and open source projects.
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Dave Roberts
fray... ;-)
Wade Humeniuk wrote:
> You have not answered my question. Why are you holding up CL to
> a different standard (and thus the people around it)?
> Your implication is that it is a superior language, thus it
> has to have single monolithic authoritative standard libraries.
> Sorry, but that is ridicdulous. I am sorry you are disappointed with the
> "other" languages and are putting your unrealistic hopes on
> CL.
The fact is, however, that CL does have a large, single, monolithic,
authoritative standard library. In fact, most of the ANSI CL spec is just
that. I mean, there really isn't much to Lisp once you get past the reader
and eval. Pretty much everything else is library.
The only question I'm asking is, "Why stop basically at CAR and CDR? Why not
include modern language support for things like threads and networking?"
Note that I'm not holding CL to a higher standard that all other languages
(and I'm not Cameron in any case, so your response was not directed at me).
The fact that C doesn't include some of these things is actually a problem
for it long term, too. The fact that C is a bit "closer to the metal" than
most programming languages will save it, however. It's what you use to
implement the lowest layers of your Java, Perl, Python, .NET, and Lisp
runtime, after all.
But for a high level language, it's just routine to include those sorts of
things these days. In fact, all those languages mentioned above *except*
Lisp, have these features. And they are the "growth" languages. Even .NET
with C# has a standardized basic library which is being implemented in
Mono.
--
Dave Roberts, ldave-...@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Dave Roberts
> In fact, you can have a compliant JVM that has no support for networking
> as well. OMG! I see your Standard and raise you an Implementation.
Hmmm... I don't think so (but I could be wrong). That is, java.net.* isn't
optional. It's a required package. You might not have a stack on the
machine you're running on, but in that case, you would just have a java.net
implementation that couldn't connect to anything (just return errors). It
would still be required to be there and for the API to be consistent with
the standard API.
> If anything, we hold CL to a higher standard to let us concoct any API
> that suits us to facilitate the task at hand.
Will, sorry, my original posting wasn't meant to start a flamefest. I guess
the question is, where does "standardization" fade out. Surely, we all
agree that CAR, CDR, and LIST should be the same on all implementations,
right? How about MAPCAR? How about...? The question is, how far should we
go?
I guess that I'm saying that things like network libraries are very useful,
and I'd like to take advantage of the synergy of the collective to get
ahold of useful code. While I certainly wouldn't restrict your right to
"concoct any API that suits" you, I do find it helpful to have a baseline
API that is standardized across implementations. In other words, if you
want to design a replacement for MAPCAR that works great for your needs,
have at it. But I'd really like to have a standard MAPCAR that I can rely
on. This is simply a level or two up from that.
Carl Shapiro
> I think there is something of a disincentive for implementers to back
> standardization efforts because it makes it easier for their customers
> to switch to other vendors. OTOH, it also makes it easier for the
> customers of other vendors to switch to them, so it may be a wash, I
> don't know.
I think the benefits for vendors far outweigh the remote possibility
of their customers disappearing. Having good interface standards
means that their customers can readily import the work of other Lisp
developers. It is just not possible to architect a large software
system across multiple organizations in Lisp today unless everybody is
using the same Lisp. There is a lot of money available in these types
of projects, and right now that money is out of reach for people who
want to write their wares in Lisp. Developers who wish to work in
Lisp can do quite well for themselves on smaller scale projects, and
that's okay. But overall, Lisp would be in a much better position if
there wasn't so much friction associated with its use when a project
outgrows that niche.
Dave Roberts
> Why should I assume "multiple independent (by default) execution
> contexts with a shared heap" runtime model best fits all application
> domains ?
Threads aren't the best model for every problem. But they are useful for a
great many problems. The question isn't "Should we force every program to
use threads?" Rather, it's "If you want to use threads, should we force
your code to be non-portable?"
> On the other hand I'd love to have an abstraction over things like
> /dev/poll , select, kqueue and whatever Win32 has (I/O completion
> ports?) as some library for CL.
Yup. So would I. Chalk those up on the API list, too. That's effectively
what Java did with NIO. They realized that both models are useful at
various times.
> Also, Java Threads or n/w API syntactically may not change across
> platforms, but I don't know if it works the same. I think people do
> have to "worry about the idiosyncrasies of their vendor's network API or
> threads API" (this is just a guess on my part).
There are some subtle differences, but unless you're doing something really
hairy, you typically don't have to worry about things too much.
> If standard thread support is such a good idea, why the need for
> non-blocking I/O ?
Because they are both useful paradigms. They didn't obsolete threads or even
deprecate them. They simply recognized that for certain server applicatios
where high scalability is desirable, non-blocking I/O is more scalable.
Where low scalability is all that is required, a thread is a great
programming help
> Once I use non-blocking, I am into event model programming, the
> simplicity of sequential model is lost. I'd rather have either the
> simple non-threaded with blocking I/O sequential model, or the
> non-threaded event model with non-blocking I/O (when performance is
> needed) where performance is gained at some cost to complexity . Having
> both threaded blocking sequential , and the non-blocking I/O event model
> in one app is complexity beyond what I want to have.
So write your app with one model or the other. Nothing forces you to use a
given API. It's just there waiting for you if you want it. As an example, I
bet that you don't have half the functions in today's CL ANSI standard. Yet
they're all there in a conformant implementation, ready if you decide they
are useful.
Dave Roberts
>
>> Why don't more implementers and users feel the need for further
>> standardization?
>
> I think there is something of a disincentive for implementers to back
> standardization efforts because it makes it easier for their customers
> to switch to other vendors. OTOH, it also makes it easier for the
> customers of other vendors to switch to them, so it may be a wash, I
> don't know.
>
> In other words standardization leads to commoditization.
Generally, standardization is bad for a vendor when the vendor has large
market share and the item being standardized is really valuable and unique
in some way.
On the other hand, standardization is good for vendors when the thing being
standardized is just table stakes for everybody. In other words, when it
has become a commodity already, keeping it non-standard just fragments the
market and slows down innovation because everybody keeps spending their
time solving the old problems again and again, rather than the new problem
that would lead the industry forward.
As an existence proof, look at what Linux is doing to the fragmented Unix
market. It's simply killing it. Linux is a defacto standard that finally
has everybody saying, "Gee, why are we writing code to all these niche Unix
variants when we could be spending time on other things...?" The reality
is, nobody competes on Unix implementation now. We all just use Linux
(well, except those BSD boys, but you know how THEY are... ;-).
> There is also another point. Vendors should be customer driven. But
> customers usually want features. If my Lisp already has a thread
> implementation, an FFI, and a networking library, a vendor is more
> likely to address things the implementation doesn't have that
> customers are demanding rather than worrying about standardization
> efforts. If customers demand standardization that might make a
> difference --- the Common Lisp standard grew out of a very large
> customer's demand for it. That very large customer eventually cut and
> ran after the standard was developed, but that's another issue.
Yup, vendors have to see value in it. If they don't think it would expand
the market, they won't do it (and as a shareholder for a public company,
I'd tell them not to do it). The goal here has to be to raise the level of
basic interoperability and grow the market or make it easier to implement
functionality. Effectively, standardization says, "As vendors, we aren't
going to try to compete on this stuff. It's just so fundamental that we
feel that everybody should do it the same way so that neither the vendors
nor the users will have to even think about this stuff."
As I said in another post, we standardized CAR, CDR, LIST, MAPCAR, etc...
But the bar is always being raised. Now things like networking and threads
are in pretty much every operating system. Why are we "competing" on those
items? Is there really any benefit to us to keep that portion of the CL
APIs fragmented, or would we be better off agreeing that those things are
not worth competing over any more and instead we'll compete on some other
API that really distinguishes ourselves.
> OK, so why don't more users feel the need for further standardization?
> Well, I'd argue that satisfied users don't care that much about
> standardization. That's because they aren't looking to change
> vendors, so they don't care if their programs run on another vendor's
> implementation. Customers with a long term view might be more
> sensitive to standardization but again it may not be a priority.
Yea, but that's sort of the legacy Unix argument. "Hey, I'm running Solaris,
so what do I care about HP-UX?" Well, the reality is that you don't care
about the other implementation, but you should care about something like
Linux that will come along and undercut both of you.
> The kind of users who care about standardization are usually trying to
> run cross-platform. It is apparently more desirable for vendors to
> make their implementations run on all leading platforms than to worry
> about standardization.
Not, that's not true. Even if you never want to move off your chosen
platform, you may still want to be able to use code easily that was written
by somebody using a different platform.
Put another way, I have basically converted to doing all my Java development
on Linux. But I like the fact that when I download a Java library, I don't
care whether the programmer wrote it on Windows or AIX. It just works and I
don't have to spend much time at all thinking about porting. That's a good
thing. Even if users don't flow over to the other implementation, it makes
code flow between them.
And that then increases the network effect which in turn creates positive
feedback for the development community.
Edi Weitz
> So I'd suggest that Edi's CL-PPCRE knocks off regexps. I don't know
> of any reason *not* to use it. Fast, portable, and mind-share
> compatible with Perl (as much as is possible or desirable.
>
> He seems to have done the work of making sure it runs on just about
> every available CL implementation though he hasn't--according to his
> web page--been able to personally test every new version he's
> written on all the impls. Presumably he would be happy to get bug
> reports from someone who actually uses a particular implementation.
Yep.
David Steuber
> The only question I'm asking is, "Why stop basically at CAR and CDR? Why not
> include modern language support for things like threads and networking?"
I certainly would like a standard threads API and networking API.
However, I have some random thoughts.
I expect that imitating the BSD sockets library, complete with both
blocking and non-blocking IO with select is not too complicated next
to threads. Worst case, you use an FFI interface that you put an
abstraction layer on top of. It may not be the most elegant solution,
but at least you would be where Perl is today.
I suspect threading is much more difficult. With C, you know that
some things are not going to be thread safe. Those things you create
a mutex of some sort for and just deal. But what about Lisp? The GC
has to be thread safe. Introducing threading into a system that is as
abstracted from the hardware as Lisp is has a system wide impact. So
far as I can tell, it looks like the worry is now duplicated for both
the implementation and the user. The implementation needs a thread
safe GC. The user needs to worry about what needs to be mutexed.
Maybe I am making things harder than they are.
My inclination would be to continue with a Darwinian model. Let it be
done by the libraries. As the number of libraries that do foo are
ruduced by popular vote, they can start to compete based on
portability. From the other direction, implementations of CL can
compete on the basis of what libraries they support.
As a user, I'm going to go with the implementation that has the
features I need. Features included library support. Making code
portable is a secondary concern for me. I get to choose my hardware
and OS. I get to choose my implementation.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Matthew Danish
> Or maybe the folks working on Lisp In A Box will include [cl-ppcre] in
> the box so all the newbies they attract will discover that Lisp has
> regexps "out of the box".
``Try out (clc:load-system 'cl-ppcre), for example, to load Edi Weitz's
Perl-compatible regexp system.''
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish
> It would be great if Lisp had more standard libraries for things like
> networking.
I'm starting to wonder how many people in this thread actually sat down
and tried to write portable networking code in CL? I did, a while ago,
I wrote a simple FTP library in a few hours using ACL-COMPAT and it
works fine on a number of implementations that I have tried out. I
didn't even think about the fact that Common Lisp has no "standard"
networking library, yet I still managed to get it done, somehow.
Cameron MacKinnon
> Getting implementors to agree on a common API for XYZ is hard, especially
> when they all already have their own competing ones.
And it gets harder every month, because their users will have written
that much more code using the APIs which will end up deprecated.
> What should be a lot easier for them to agree on would be the set of
> features a given API should provide -- you could even split this
> into "basic" and "extended" features.
Once they've agreed on that, naming the functions differently seems like
being different just to be different.
> It might also ease future standardization of the actual API, as the
> common feature set might in practical terms translate into convergence.
In practice, I think this already happens a lot. Implementors and users
read other implementations' manuals, and any feature which isn't bad,
marginal or useless is likely to be copied in some form or another.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon
> Yes, I disagree. CL is general puprose. Each implementation has
> a standard api. CL applications are quite capable of networking.
...
> CL is just as standardized as any other language out there. Specific
> implementations have their own standard interfaces.
"What we have here is a failure to communicate." I'm not advocating
standards in the sense that "the great thing about standards is that
there are so many to choose from." I think you and I have different
ideas about the meaning of the word 'standards' in this context, or
you're just deliberately trying to inject noise into the channel.
Cameron MacKinnon
> No, they only have to worry about the idiosyncracies of their network or
> threads IMPLEMENTATION. While a "standard" API is all peachy and wonderful,
> there's nothing to stop someone from having crappy implementations
> underneath that shroud of "compatability". Java has had a long and sordid
> history with regards to threads (who's API has, in fact, changed in the
> past).
When a vendor releases crap and wrongly calls it conforming, you can hit
him over the head with the standard and (often) embarrass him into
conforming. Without the standard, customers have less cause for
complaint. Your argument is that standards won't necessarily lead to
utopia, and I agree, but do you believe that they'll make things worse,
or cause no improvement?
> Just to be clear that you consider C, C++, FORTRAN, Ada, Delphi, and, of
> course, probably the most recently standardized of languages, arguably the
> most "modern" mainstream language, C#, on those same grounds. None of those
> lanaguages have a "standard" network API. Popular ones? De Facto ones? Sure.
> Oh, wait, so does CL!
I'm pragmatic about my standards. "The same everywhere, and codified" is
good enough for me. Barring that, I can live with "the same everywhere,
specified by its implementation" because it beats the alternatives.
Since you appear to want to drag me down into comparisons with low
languages, I'll indulge you, just this once:
- C, C++: Have a consensus network standard, BSD sockets. Given
Microsoft's behaviour toward other standards, their gratuitously
nonconforming copy of this one is proof that it is, indeed, the standard.
- FORTRAN: No longer considered a general purpose language,
inapplicable. Pipe stress freaks do however have PVM and MPI.
- Ada: I don't know enough to comment.
- Delphi: As a single implementation language with networking
(right?), it meets my criteria.
- C#: Ditto
> In fact, you can have a compliant JVM that has no support for networking as
> well. OMG! I see your Standard and raise you an Implementation.
There's always room for incomplete implementations that don't contain
the feature in question because they're running on four relays and a NOR
gate. Are you seriously suggesting that there's no difference between
that and a world where every implementation's version of feature X has a
different API? I assume not.
Cameron MacKinnon
> Cameron MacKinnon wrote:
> ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL PURPOSE YET HAS NO
> STANDARD NETWORK API IS INFERIOR IN THAT RESPECT, AND INDEED BLIGHTED.
> Do you disagree?
>
> I agree, but I almost missed the "IN THAT RESPECT" :)
I only put the phrase in after some reflection. :-)
Cameron MacKinnon
> I suspect threading is much more difficult. With C, you know that
> some things are not going to be thread safe. Those things you create
> a mutex of some sort for and just deal. But what about Lisp? The GC
> has to be thread safe. Introducing threading into a system that is as
> abstracted from the hardware as Lisp is has a system wide impact. So
> far as I can tell, it looks like the worry is now duplicated for both
> the implementation and the user. The implementation needs a thread
> safe GC. The user needs to worry about what needs to be mutexed.
>
> Maybe I am making things harder than they are.
I think you are. Simplified explanation: To GC, you trace all the
objects pointed to by the CPU's registers, and all the objects those
objects point to (including the objects on the Lisp stack) etcetera.
Anything you don't eventually reach is garbage. For threads, you just
have to consider each thread's set of saved registers (including the
stack register) as well. As for mutexes, same as any language: If you
don't use threads, you don't need them, and if you do, you should know
when you need them.
> My inclination would be to continue with a Darwinian model. Let it be
> done by the libraries. As the number of libraries that do foo are
> ruduced by popular vote, they can start to compete based on
> portability. From the other direction, implementations of CL can
> compete on the basis of what libraries they support.
Well, there's probably people who would hesitate to throw their
libraries into the ring if they'd be subject to a popularity contest.
Realistically, extinction in the age of the permanent web page is
extinct, though bit-rot is with us as ever.
I'm not advocating standardizing xml-foo, soap-in-a-.net-quux etcetera.
There's many flavours of the month in other languages which are already
on the decline by the time the ink's dry on the standard, and I don't
want a language overburdened with cruft that didn't stand the test of
time. But some things, such as international language support,
networking &c, are here to stay and have been with us long enough that
sensible people can agree on an API.
Cameron MacKinnon
> The thing holding back the development of ANY library, much less a portable
> library, is developers writing them. Period. That's the "problem".
Nope. CL developers are writing libraries, they have to be. But they may
not release them because they don't see a big enough audience for the
thing to become self-sustaining. Few things are more pitiful than coming
across a web page for libfoo-0.3, last updated 5 years ago, with no
contributions from anyone but the author. People know this, so if they
think the audience is three people, they don't bother releasing. And
audience IS reduced if your library isn't portable because it relies on
language features which every implementation has, but differently.
> It is clear to me that these users of CL are not using CL because of its
> "vast array of libraries", nor are they (necessarily) using it for its
> portability.
Sure. Those of us using CL obviously aren't using it for what it hasn't
got. But if it had more useful libraries, more people might use it, and
those of us who do use it would become more productive, almost
automatically.
> Portability is only important when you want to share vast amounts of source
> code, which is something pretty much "unique" to the OSS world, but less
> important to the "real world".
Portability is also important if you're worried about your vendor going
broke.
As well, there's lots of proprietary ("real world") software developed
on top of OSS substrates. Commoditization (creating one or more good,
open implementations) of the lower levels of the software pyramid
benefits everything, commercial or proprietary, that is built above
them. But I don't want to turn this into a debate about open source.
Chris Hall
>
> Getting implementors to agree on a common API for XYZ is hard, especially
> when they all already have their own competing ones.
>
> What should be a lot easier for them to agree on would be the set of
> features a given API should provide -- you could even split this
> into "basic" and "extended" features.
>
> This would give people worrying about portability some reassurance, since
> they could rest easy in the knowledge that the features they use are
> portable, even if the interfaces may differ.
>
> It would also faciliate writing of portable interfaces, since a modicum
> of common ground would be more or less guaranteed,
>
> It might also ease future standardization of the actual API, as the
> common feature set might in practical terms translate into convergence.
>
> Just an idle thought,
>
> -- Nikodemus
Something like Python's DB API?
http://www.egenix.com/files/python/DatabaseAPI-2.0.html
--
People with courage and character always seem sinister to the rest.
-- Hermann Hesse (1877 - 1962)
Cameron MacKinnon
> On Thu, May 06, 2004 at 09:24:25PM -0500, adam connor wrote:
>
>>It would be great if Lisp had more standard libraries for things like
>>networking.
>
>
> I'm starting to wonder how many people in this thread actually sat down
> and tried to write portable networking code in CL? I did, a while ago,
> I wrote a simple FTP library in a few hours using ACL-COMPAT and it
> works fine on a number of implementations that I have tried out. I
> didn't even think about the fact that Common Lisp has no "standard"
> networking library, yet I still managed to get it done, somehow.
Why don't you look at this from the perspective of someone who is new to
Lisp, or evaluating it? The Hyperspec doesn't address networking code.
If he follows his implementation's manual he gets non portable code
(unless he's using something that's already compatible with ACL).
Likely, nothing a newbie would initially stumble upon would point him to
ACL-COMPAT, so by default, he writes non-portable code.
Can you see how he might view this as suboptimal? How he might think
that this language has yet to get with the '90s?
For your code to work, users have to get ACL-COMPAT, unless you've
included it. So your code is, at most, "portable, with dependencies."
And that opens up a whole new can of worms. No problem, you've probably
used one of those portable dependency systems, right?
Say a newbie just wants to install a Lisp and cut and paste an example
of networking code from a web page. Can't be done (unless the page has
implementation specific, non portable networking code on it), can it?
He's got to get either an extra package manager or an extra network
portability shim, install them correctly, then get the network code.
I suspect that Lisp In a Box solves the above, except for
inconsistent/incomplete documentation. Maybe LIAB is the new standards
track?
Matthew Danish
> Why don't you look at this from the perspective of someone who is new to
> Lisp, or evaluating it? The Hyperspec doesn't address networking code.
Neither does ANSI C. Nor should it, I don't see how anything so OS and
network specific could ever be included in a general-purpose language
standard.
> If he follows his implementation's manual he gets non portable code
> (unless he's using something that's already compatible with ACL).
>
> Likely, nothing a newbie would initially stumble upon would point him to
> ACL-COMPAT, so by default, he writes non-portable code.
When I was a Unix C newbie, I did not initially stumble across BSD
socket API. In fact, it took quite a while for me to get around to it.
And it still isn't very portable, even among various Unix, for example
on Solaris you have to include a specific library to get it. I really
don't see how that is a problem. Similarly for SDL_net or other
portable networking libraries that might have a chance of working on
non-Unix platforms.
> Can you see how he might view this as suboptimal? How he might think
> that this language has yet to get with the '90s?
> For your code to work, users have to get ACL-COMPAT, unless you've
> included it. So your code is, at most, "portable, with dependencies."
> And that opens up a whole new can of worms. No problem, you've probably
> used one of those portable dependency systems, right?
Network programming in the 90s meant either fiddling with BSD socket API
on Unix, or figuring out Winsock on Windows (and I have no idea for Mac
OS). Or you could find a portable networking library (libnet, SDL_net,
djb's) which you had to separately install anyhow.
Quite frankly, if someone can't be bothered to load a library, then they
probably can't be bothered to program either.
Of course, I totally agree that library distribution needs to be
facilitated. That's why ASDF is so easy to install (one file), and
CLiki exists to give pointers. The infrastructure exists, but it will
take time for anything to get established. Fortunately, there are
people out there who are actually working on the problem.
Dave Roberts
> On Thu, May 06, 2004 at 09:24:25PM -0500, adam connor wrote:
>> It would be great if Lisp had more standard libraries for things like
>> networking.
>
> I'm starting to wonder how many people in this thread actually sat down
> and tried to write portable networking code in CL? I did, a while ago,
> I wrote a simple FTP library in a few hours using ACL-COMPAT and it
> works fine on a number of implementations that I have tried out. I
> didn't even think about the fact that Common Lisp has no "standard"
> networking library, yet I still managed to get it done, somehow.
>
So that's great. I'm happy that ACL-COMPAT is out there. The question is, if
I want to build up a larger program, and this library over here uses
ACL-COMPAT, and another uses this other compatibility layer, and this one
over there uses some homebrew compat layer. How does that all work
together? Does it work well? Poorly? Do they interfere? How much bloat and
integration are we willing to carry? How much performance am I losing with
all these layers?
Just so we're clear, maybe the answer is to "standardize" on ACL-COMPAT. I'm
probably okay with that. But I'd rather have just one homogenization layer
than 20 in a large program.
Now, I think networking is actually the easiest to handle, though. Things
like threads definitely have interaction effects.
niko...@random-state.net
> And it gets harder every month, because their users will have written
> that much more code using the APIs which will end up deprecated.
I would dispute both the setting of relevant timeframe in months (years,
maybe), and the actual effect of this: a deprecated API is not same as a
defunct one, not even the same as an unsupported one.
The latter is further effected by the old API in all probability living in
a different package then the new one, and the cost of maintaining the old
API is lessened assuming that the new API is a superset of the old -- the
old API can be transformed into a compatibility layer built on top of the
new one. What if the old API is not a superset? Well, then someone made a
bad standard that left out important features. ;-)
>> What should be a lot easier for them to agree on would be the set of
>> features a given API should provide -- you could even split this
>> into "basic" and "extended" features.
> Once they've agreed on that, naming the functions differently seems like
> being different just to be different.
Not necessarily. Take FFI for exaple: Is FOO a function, macro, or a
special form? Can you compile a call to a foreign function before the
relevant foreign code has been loaded? How does the FFI interact with GC?
The looser the first spec is, the easier to it is to agree on, and the
less it's worth -- obviously.
I'm wondering if there might be a sweet spot somewhere there -- specific
enough to be valuable, but loose enough for multiple implementors to agree
on. Maybe such a spot doesn't exist.
>> It might also ease future standardization of the actual API, as the
>> common feature set might in practical terms translate into convergence.
> In practice, I think this already happens a lot. Implementors and users
> read other implementations' manuals, and any feature which isn't bad,
> marginal or useless is likely to be copied in some form or another.
Yes. But how soon, and how it will be integrated with the existing system
is quite a different matter...
As you see, there _is_ convergence. It's just not blazingly fast.
Cheers,
-- Nikodemus
Chris Hall
> Erann Gat <gNOS...@flownet.com> writes:
>> The Lisp code I run on my Mac won't work on any Lisp I can get for
>> my Linux machine -- whether or not I pay for it.
>
> If you haven't already, you might want to look at the Port package
> from CLOCC [1]. I've found it very helpful, and I am a bit surprised
> it doesn't get more notice during these discussions of "standards" for
> CL. For me, instead of learning the particular network/thread API's
> for Allegro, I could just learn the general Port interface, and my
> skills and code are more or less transferable to other CL
> implementations on other platforms. Very nice.
>
Thank you! I agree with your points, and through this whole thread,
I've been wondering if/when CLOCC would get mentioned, as it seems an
obvious, related topic.
If one looks at the CLOCC network code, one can begin to appreciate some
of the challenges involved with this approach, and see some examples of
the (sometimes wildy) varying APIs in various Lisp implementaions.
> I admit I haven't tested it much, but the (mostly networking) code I
> have tested has worked fine on SBCL, CMUCL, and ACL on Linux/x86. From
> the code it looks like it should work on other
> implementations/platforms as well.
Good the hear that.
I use GCL, and got interested enough in CLOCC to try and 'improve' the
'half-hearted' support for GCL, specifically in the network portion.
(That has led to some GCL-specific issues that we are currently
discussing on gcl-devel. Some parts *do* work on GCL, just not the ones
I am most interested in. Of course. ;-D)
Your comment, to me, indicates the usefulness of the CLOCC approach.
Even if all the +gcl, -CMUCL, etc. leads to a rat's nest of ugly looking
seeming kludges (my opinion), as long as it works reasonably reliably
I'm happy.
Based on everything else I've read on this thread, CLOCC, CL-PCRE and
CL-SQL seems to be the closest things to 'solutions' to what the OP was
talking about - they exist today, seem to be well on their way and are
at least 'open', if not truly free - so we can learn from and extend
those as experience and needs dictate.
Aloha,
+Chris
--
America's one of the finest countries anyone ever stole.
-- Bobcat Goldthwaite
Fred Gilham
Carl Shapiro <cshapi...@panix.com> writes:
I agree with your overall point, I think. But it's still a user
concern. You're saying that users (developers) would be better off if
they could write and share code without caring about which vendor's
version of Lisp the code was written for, and this would facilitate
large scale projects. That makes sense to me. But vendors want you
to care about which version you're using, so you'll buy their product
instead of their competitor's. So users have to demand standards or
vendors won't make standardization a priority.
I think you can see this by looking at the actual behavior of Lisp
vendors. Franz, for example, has certainly not kicked around and
trampled on the idea of standardization --- they even put forth the
"simple streams" proposal. But that's about it from what I know.
They haven't tried to push for much else in the way of
standardization. If standardization were such a good thing for
vendors, they would have pushed for it. In fact, though, vendors are
traumatized by standardization (unless they can get their
implementation of everything to be the standard).
--
Fred Gilham gil...@csl.sri.com
Democracy and capitalism seem to have triumphed. But, appearances can
be deceiving. Instead of celebrating capitalism's virtues, we offer
it grudging acceptance, contemptuous tolerance but only for its
capacity to feed the insatiable maw of socialism. We do not conclude
that socialism suffers from a fundamental and profound flaw. We
conclude instead that its ends are worthy of any sacrifice including
our freedom... -- Janice Rogers Brown
Wade Humeniuk
>
> "What we have here is a failure to communicate." I'm not advocating
> standards in the sense that "the great thing about standards is that
> there are so many to choose from." I think you and I have different
> ideas about the meaning of the word 'standards' in this context, or
> you're just deliberately trying to inject noise into the channel.
>
Quit with the personal insults.
You seem to have some nebulous idea about what is a language standard.
The CL ANSI specification is a whole different thing than commonly accepted
libraries. Lets take one of the best known and widespread APIs,
the BSD socket interface. The language is C, but it is not a
C language standard, its a OS (originally BSD Unix) standard and
since the system language of BSD is/was C then it was easily ported. But
its NOT a language standard. Java tries to be not just a language
but also an OS layer on top of all other OSes. It strives to be a whole
environment and thus it needs to create "standard" ways of doing
things to prevent duplication. The Lisp Machines have standard
ways of doing things, but most CLs do not strive to be OS like
anymore. What you are asking for is not standards for Lisp, but
standard (accepted) ways of doing things in your idealized Lisp Machine.
Conflating the ANSI standardization process with common user practices
just creates a mess. One has to realize where formal language standards
are useful and when its time to stop.
Wade
Frank A. Adrian
> You seem to have some nebulous idea about what is a language standard.
> The CL ANSI specification is a whole different thing than commonly accepted
> libraries.
You seem to be stating that anything that's "in a library" should not have
standard supported bindings. By that argument, file interaction should
not be standardized because it's not part of a language, but accessed
through an API (granted, anyone who's worked with pathnames knows the
horrors of the standardized feature, but...). Nor should memory
management, because raw memory allocation is accessed via an API.
The fact is that OS'es move forward and things that were special case
become commonplace. Models congeal and OS'es support those models. The
fact is that, just as 20 years ago, OS'es had file system models that were
common enough to allow relatively simple abstractions to be built into the
standard, today most OS'es (and Lisp implementations) have threading
models and socket abstractions that are common enough for standardization.
Are you really saying that forcing Lisp programmers to use (relatively)
hard to inject libraries to write portable code is a good thing? Even as
a long time Common Lisp user, I find this to be an annoyance. The bottom
line is that facilities such as UFFI and PORT should be either bound into
shipped CL systems, easily loaded (one "require" statement at most,
without having to load "asdf" or some other crud), or those packages be
used as the starting point for standardization efforts for those
facilities. And, I admit, this is not for any desire for a larger market
share, or larger user base for the language -- it's simply to make it less
of a pain in the ass for me to use these facilities.
So! Why don't I write my own system to do that? Well, to be blunt,
there are already too many systems, all providing access to the same
capabilities, but with incompatible interfaces (sort of like the problem
with all of the Lisp variants around, say, 1978 or so). The point of a
standard is to clear away the clutter to formally say that *this
particular interface* is the way we, as a language community, have decided
to access these features so that we no longer have this particular pain in
the ass. I think there are some features that have progressed to that
point. Perhaps not UI (probably not ever) and perhaps not code dependency
management, but multiprocessing, foreign function interfaces, and socket
interfaces have reached that point, just as file system interfaces had 20
years ago and memory management 40 years ago.
Not standardizing these things at this point is simply a form of software
masochism.
faa
Dave Pearson
> For your code to work, users have to get ACL-COMPAT, unless you've
> included it. So your code is, at most, "portable, with dependencies." And
> that opens up a whole new can of worms. No problem, you've probably used
> one of those portable dependency systems, right?
That's the sensible thing to do isn't it? A couple of weeks back I modified
some code I wrote a short while back (a dict.org client) to use ACL-COMPAT
and packaged it up with asdf and chucked a pointer to it onto Cliki. I wrote
it with SBCL on my GNU/Linux box. A friend who isn't really that into CL
threw SBCL and OpenMCL onto his Mac, did an asdf-install of my package in
them both and everything "just worked".
> Say a newbie just wants to install a Lisp and cut and paste an example of
> networking code from a web page. Can't be done (unless the page has
> implementation specific, non portable networking code on it), can it? He's
> got to get either an extra package manager or an extra network portability
> shim, install them correctly, then get the network code.
From where I'm sat it looks like some distributions are dealing with the
package manager "problem". SBCL comes with asdf "out of the box", doesn't
OpenMCL too? And I think I read somewhere that clisp is heading this way as
well.
If all of this is a problem then it looks to me like one that is getting
solved by people who are writing code.
--
Dave Pearson
http://www.davep.org/lisp/
Wade Humeniuk
> with all of the Lisp variants around, say, 1978 or so). The point of a
> standard is to clear away the clutter to formally say that *this
> particular interface* is the way we, as a language community, have decided
> to access these features so that we no longer have this particular pain in
> the ass. I think there are some features that have progressed to that
> point. Perhaps not UI (probably not ever) and perhaps not code dependency
> management, but multiprocessing, foreign function interfaces, and socket
> interfaces have reached that point, just as file system interfaces had 20
> years ago and memory management 40 years ago.
>
> Not standardizing these things at this point is simply a form of software
> masochism.
This is why I stick to one implementation of Common Lisp, LispWorks.
LispWorks has multiprocessing, FFI and socket interfaces, but (here is
the difference), I have made a commitment to one implementation
and try not to thrash around between implementations. Some people
seem to not want to commit to any particular language or implementation
and will just drift through life with no concrete results.
My personal view is that if I write an application that is really
useful and used and it has to move to some other implementation then I
will have the resources (financial and otherwise) to do that. BUT
first that app has to be actually conceived and written, not just
some pie-in-the-sky that runs on a idealized platform. Common Lisps
can do all those multiprocessing, networking, FFI and database
things already, there is no lack, it is not holding anyone
back.
Wade
Duane Rettig
I tend to agree with this. Vendors certainly do care about standards.
And although users can make guesses about what the vendors' motivations
are for pushing or not pushing standards, these guesses are almost
always wrong because they are too simplistic - the question of
when/whether to push for what standard is always complex - it includes
components of competiton within the language, general market size
and expansion, usability, etc. I've heard many good arguments by users
in this thread, and it irks me a little that the implications have been
(not necessarily by you, Fred) that the vendors don't think about all
of these things, too. We just don't tend to talk about it much in a
forum like this, because anything we say can and will be taken as
self-serving.
> I think you can see this by looking at the actual behavior of Lisp
> vendors. Franz, for example, has certainly not kicked around and
> trampled on the idea of standardization --- they even put forth the
> "simple streams" proposal.
Note that this falls under your "their own implementation as standard"
category, below. Also included in this are a number of opensource
modules, such as AllegroServe, from which Portableaserve is built, as
well as several other modules at http://opensource.franz.com.
> But that's about it from what I know.
> They haven't tried to push for much else in the way of
> standardization.
Well, let's see now:
- We worked with the other major CL vendor at the time (Harlequin,
now Xanalys) to create an official Lisp binding for Corba.
- We're working on bringing Environments Access back from the CLtL2
grave, and will eventually contribute it to opensource.
- One of my colleagues is the chair on the NCITS (the body that
carries on the work of what the X3J13 committee originally did).
It is interesting that people blame vendors for not being interested
in standards; when the rubber meets the road (i.e. you have to pay
yearly dues), very few people are signed up on that committee.
> If standardization were such a good thing for
> vendors, they would have pushed for it.
Right, absolutely :-)
> In fact, though, vendors are
> traumatized by standardization (unless they can get their
> implementation of everything to be the standard).
I am not in a position to say whether this is true or not, since
many of the standards (in as many senses of the word "standard" as
you care to consider) which we work on are backed by our own
implementations. But this is an unfortunately cynical point
of view. Perhaps Microsoft _has_ won, after all; their business
style has captured the hearts and minds of programmers everywhere.
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Pascal Costanza
Dave Roberts wrote:
> So that's great. I'm happy that ACL-COMPAT is out there. The question is, if
> I want to build up a larger program, and this library over here uses
> ACL-COMPAT, and another uses this other compatibility layer, and this one
> over there uses some homebrew compat layer. How does that all work
> together? Does it work well? Poorly? Do they interfere? How much bloat and
> integration are we willing to carry? How much performance am I losing with
> all these layers?
You are making this up and describe in exaggerated terms what you
probably haven't even experienced yet yourself. Am I right?
I think that when you start to focus on real problems, you will notice
that things aren't that bad, but in fact continually improving.
This discussion reminds me of a distinction that, I think, Richard
Gabriel has made in his book "Patterns of Software". There is a
difference between the notion of reusable code and reused code. The
important point is that you cannot deliberately write reusable code, but
you can only reuse existing code and, during that process, create code
that is indeed reusable. This resonates with experiences made in the
component community: the wisdom there is that you cannot rightfully
consider something a component (in the Szyperski sense of a black-box
component) when it hasn't been used in at least three different settings.
Since portability is just another variant of reusability, one can
equally make the distinction between portable and ported code. Likewise,
you cannot write portable code, you can only port existing code and thus
create portable code.
In the early Java days, I have been involved in several projects where
we actually counted on the "write once, run everywhere" feature. The
truth was rather "write once, test everywhere", and we had to change the
code several times, and add several exceptional cases, in order to make
it really work. And I don't think this was because Java sucks in that
regard. To the contrary, these were problems that we wouldn't have even
thought of in other languages. (Java sucks, but because of other reasons.)
The apparently widely held belief that you only need to standardize
stuff in order to get portable / reusable code is a pretty bad idea.
This is an impression largely supported by companies who invest lots of
money to increase their market share in order to control it. However,
there are examples that prove that it doesn't work that way. Someone in
this thread already mentioned JDO vs. Hibernate. I also remember the
Java Generic Library that was superior to the collection framework in
the JDK but was still swamped out by Sun. There are numerous other examples.
The good thing about Common Lisp and its ANSI standard is that it is
mainly derived from decades of actual programming experience with Lisp
dialects. So this standard is a unique example of things that weren't
designed and then forced upon a community without actual experience, but
just the other way around: Lisp programmers identified common idioms and
agreed upon compromises between mostly superficial differences. I
haven't been part of that process, because I am just too young, but you
can just _feel_ that experience built into the language by simply using
it for real programs. More often than not, when you have a problem in an
area covered by the standard, you will find a solution that works
exactly like you need it, as if it just waited for your problem.
I think it's a worthwhile goal to keep it that way. I don't want the
millionth library standard that doesn't live up to its promise. First
gain experience, and then mold it into something more general, not the
other way around.
So my actual suggestion is: Pick out _one_ Common Lisp implementation
that best suits your needs, according to whatever criteria you have, and
then start to write your programs, applications, services, whatever.
When it turns out that you need some other library only available for a
different CL implementation, consider porting it, and in this way
creating a portable version. When it turns out that someone else needs
your libraries, they will probably consider porting it to their
respective environment, and so on. At some stage, there may or may not
be different approaches to solve similar problems, and perhaps then
people can talk about standardizing stuff based on actual experience.
The only thing that is missing here is a kind of semi-official forum in
which one can actually suggest standard APIs, and discuss and agree upon
them. But I think that www.cliki.net and www.common-lisp.net are
actually quite close.
Another important thing to remember: There is currently not a lot of
money in the Common Lisp community, AFAICT. Official standardization
processes are expensive. Open-source processes are also expensive.
Trying to create pressure in order to make someone do the work that you
would like to see done is very likely to fail in the Common Lisp
community. There is no large company or movement that actually listens
to you. Lisp is still considered a weird language "out there". You are
not part of a target audience that can, just because of its plain
existence, influence the direction of future developments. You can only
gain influence by actually investing something, whether this is work on
implementations, libraries, applications and services, or by buying
commercial implementations. Or so I think.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Tayssir John Gabbour
> http://lists.tunes.org/archives/tunes/2001-February/003058.html
>
> The original message looks like it is over 5 years old. I found the
> recommendations to be right on the money.
>
> I bring it up because of the two interesting recent threads titled:
> 1. "Is anything easier to do in Java than in Lisp?"
> 2. "The Hyperspec and portability between Common Lisp compilers (long)"
>
> Some of the areas for improvement suggested in this paper are things that I
> think are important for modern programming with Lisp. Things like a
> standard threads library and a standard network interface library are
> critical for Lisp to be able to develop the set of general-purpose
> libraries required for rich, modern applications. While many Lisps have
> added features in these areas, without standardization the solutions are
> fragmented and non-portable.
You've made cogent points in the discussion, but I think most of it is
wasted -- it was in response to the usual usenet bickering. Instead of
focussing on the Why?, which I think is clear, I'd be interested in
seeing a discussion of the proposals.
- concurrent processor stuff: network, threads, db
- ???
What languages and lisp implementations do well on these things?
Benefits/problems people encounter? What is hard to implement, and can
there be different levels of conformance?
What are the Lisps of these things, as opposed to the Javas and
Pythons?
I'm curious what peoples' thoughts are now about stack groups.
http://bitsavers.org/pdf/mit/cadr/chineualJan84/chineualJun84_13_StackGroups.pdf
I swear, if I see one more 200 post nontechnical thread saying why
something can't be done and there's no point in educating oneself
about it, I will go mental.
Erann Gat
Peter Seibel <pe...@javamonkey.com> wrote:
> Erann Gat <gNOS...@flownet.com> writes:
>
> > Sockets. Threads. Database. Regular expressions. These are the Big
> > Four that Lisp is lacking IMO.
>
> So I'd suggest that Edi's CL-PPCRE knocks off regexps.
No, it doesn't. For one thing, it doesn't work in the latest version of
MCL. And, very much to the point, it is not clear whether the reason it
doesn't work is a bug in CL-PPCRE or a bug in MCL.
But even if CL-PPCRE worked perfectly I would still argue that it does
not serve the same purpose that a standard would. If this were not the
case then standardizing CLOS serves no purpose given the existence of
PCL. For that matter, one could argue that there is no point in
standardizing anything at all, including Common Lisp itself, as long as
a portable implementation exists.
But standards do more than just encourage the availability of portable
functionality. They define invariants. They tell you which aspects of
an implementation's behavior you can count on and which ones you can't.
They provide a mechanism for determining, for example, whether the
problem with Cl-PPCRE on MCL is a problem with CL-PPCRE or MCL. And,
more importantly, they provide a mechanism by which the community can
speak with a single voice to the rest of the world.
E.
Peter Seibel
> In article <m3pt9g2...@javamonkey.com>,
> Peter Seibel <pe...@javamonkey.com> wrote:
>
>> Erann Gat <gNOS...@flownet.com> writes:
>>
>> > Sockets. Threads. Database. Regular expressions. These are the Big
>> > Four that Lisp is lacking IMO.
>>
>> So I'd suggest that Edi's CL-PPCRE knocks off regexps.
>
> No, it doesn't. For one thing, it doesn't work in the latest version of
> MCL. And, very much to the point, it is not clear whether the reason it
> doesn't work is a bug in CL-PPCRE or a bug in MCL.
>
> But even if CL-PPCRE worked perfectly I would still argue that it
> does not serve the same purpose that a standard would. If this were
> not the case then standardizing CLOS serves no purpose given the
> existence of PCL. For that matter, one could argue that there is no
> point in standardizing anything at all, including Common Lisp
> itself, as long as a portable implementation exists.
Okay. I agree. I overstated the case when I said it "knocks off
regexps". It is *not* a standard. What I was really trying to suggest
is that we have what could very well be the *basis* for a standard in
the form of a high-quality, widely-ported, documented implementation
of a reasonable API. I.e. all we have to do is *agree* that this is
the way to do regexps and we're done. Not that that last step is a
necessarily a small one. But at least step one isn't, "Collectively
design a regexp API on c.l.l." <shudder>.
The question for those of us--and I count myself as one--who think
Common Lisp would benefit from some more standards, probably de facto,
layered on top of the fine language standard we already have is what
would it it take for CL-PPCRE to actually become the "standard" way to
do regexps in Common Lisp?
> But standards do more than just encourage the availability of
> portable functionality. They define invariants. They tell you which
> aspects of an implementation's behavior you can count on and which
> ones you can't. They provide a mechanism for determining, for
> example, whether the problem with Cl-PPCRE on MCL is a problem with
> CL-PPCRE or MCL. And, more importantly, they provide a mechanism by
> which the community can speak with a single voice to the rest of the
> world.
Indeed, that last bit seems to me to be the crux of the matter. What
has to happen before "the community can speak with a single voice" on
the question of how to do regexps in Common Lisp? I don't imagine 100%
of Common Lispers could every agree on anything and there are no
law-giving bodies that are in a position to start laying down the law.
But if enough people treat CL-PPRCE as the answer to the question,
"How do you do regexps in Common Lisp?" then that might be close
enough.
If every new Lisper who asks about regexps is told to use CL-PPCRE,
vendors who care about selling their product to those new programmers
will either make sure they don't break CL-PPCRE on their impls or will
send Edi patches. Of course if they don't care about the emerging de
facto standard they will ignore it. Of course there are current Common
Lisp implementations that claim to be conformant which ignore certain
parts of the de jure language standard we already have.
Given that Edi has done most of the heavy lifting, my point is if at
least those folks who think there *should* be a de facto regexp
standard can't agree to agree that CL-PPCRE is the answer and move on
then there is little liklihood of there ever being a de facto standard
for something as complex as a threading or networking API.
I personally agree to tell everyone I know that CL-PPCRE is how to do
regexps in Lisp. If you agree there's two of us[1]. And if we can get
one more, as Arlo Guthrie says, it's a movement.
-Peter
[1] I imagine you'll want to send Edi a bug report about the problem
with the latest MCL and get it fixed before you'll agree to promote
CL-PPCRE. But I can't imagine that's a complete showstopper given that
Edi has expressed an interest in such a bug report.
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Martin Elster
> Martin Elster <mel...@turing.uio.no> wrote:
>
>> BTW: If you are thinking publishing code, I for one would be very
>> interested in seeing the code for your "locales", as presented on ILC
>> 2003. They look like very interesting, and would be fun to experiment
>> with.
>>
>> (hint hint :-)
>
> See http://www.flownet.com/gat/lisp
Very cool! Thanks.
martin
Edi Weitz
> In article <m3pt9g2...@javamonkey.com>,
> Peter Seibel <pe...@javamonkey.com> wrote:
>
>> Erann Gat <gNOS...@flownet.com> writes:
>>
>> > Sockets. Threads. Database. Regular expressions. These are
>> > the Big Four that Lisp is lacking IMO.
>>
>> So I'd suggest that Edi's CL-PPCRE knocks off regexps.
>
> No, it doesn't. For one thing, it doesn't work in the latest
> version of MCL.
So, if regular expressions are so important, as you said earlier in
this thread, why didn't you report that?
I've just grabbed my wife's iBook and downloaded the latest MCL trial
version to test against and here's what I got:
1. digitool.com seems to be down as most of the time... :)
2. Luckily, I remembered that the trial version is also available from
hotdispatch.com, so I grabbed it from there.
3. I installed it and grabbed the latest CL-PPCRE version from my
server.
4. I loaded "load.lisp" and, er, more or less nothing seemed to
happen.
5. Then I realized I probably had to load "load.lisp" "as a Unix file"
or whatever the menu entry was called. Again, not much happened.
6. So I opened up a terminal window and did
for i in *.lisp; do recode latin1..mac $i; done
And /now/ I could successfully load the whole library via
"load.lisp" (after deleting all the files that were previously
"compiled").
7. Running (cl-ppcre-test:test) gave LOTS of errors. Hmm...
8. Wait!
recode latin1..mac testdata
9. Ah! Now only four or five unexpected errors remained and from what
I see I'm pretty sure these are all about character encodings,
i.e. it's not about CL-PPCRE per se but because the test suite was
created on a Unix system.
If I'm not mistaken the only problem is that Digitool hasn't yet
realized that OS X is Unix. If you see other errors or if your version
of MCL differs significantly from the trial version that can be
downloaded please feel free to send a bug report and I'll do what I
can.
Of course it's more fun to bitch on c.l.l. :)
Cheers,
Edi.
Fred Gilham
Duane Rettig <du...@franz.com> writes:
> I've heard many good arguments by users in this thread, and it irks
> me a little that the implications have been (not necessarily by you,
> Fred) that the vendors don't think about all of these things, too.
> We just don't tend to talk about it much in a forum like this,
> because anything we say can and will be taken as self-serving.
I should say that I tend to think of Franz as "one of the good guys"
in the sense that Franz has done a lot to support the Lisp community.
I know that by experience, having seen the way Franz has helped with
the Lisp conferences, for example. So when I used Franz as an
example, I was saying something like, "Look, even the `good' vendors
like Franz aren't dying in the standardization trenches."
To be honest, I must say that most of the vendors in the Lisp
community, at least the ones I know about, are "good" vendors. I
think that because the market is relatively small, Lisp vendors that
screw the Lisp community won't stay in business.
The Hyperspec that Xanalys makes available, for example, is a major
contribution to the Lisp community,
Corman Common Lisp makes its underlying Lisp substrate available for
free.
Whoever makes MCL also made OpenMCL possible (no, I'm NOT a Mac
person!).
Having thus adequately covered my flanks (I hope) I will also say that
I expect vendors to be self-serving inasmuch as they have to make a
profit to stay in business. Please, be self-serving! Make a profit!
Because as long as there are credible vendors, they will reflect some
of that credibility on the Lisp community as a whole.
My main point is that in order to continue to make a profit, vendors
have to serve customer wants. It doesn't make business sense to put a
lot of effort into things customers aren't asking for, unless you
believe that you will be tapping an unreached market. But that is an
entrepreneurial approach, and certainly involves risk. And in my view
a standardization effort is almost the opposite of entrepreneurial.
> > I think you can see this by looking at the actual behavior of Lisp
> > vendors. Franz, for example, has certainly not kicked around and
> > trampled on the idea of standardization --- they even put forth the
> > "simple streams" proposal.
>
> Note that this falls under your "their own implementation as standard"
> category, below. Also included in this are a number of opensource
> modules, such as AllegroServe, from which Portableaserve is built, as
> well as several other modules at http://opensource.franz.com.
>
> > But that's about it from what I know.
> > They haven't tried to push for much else in the way of
> > standardization.
>
> Well, let's see now:
>
> - We worked with the other major CL vendor at the time (Harlequin,
> now Xanalys) to create an official Lisp binding for Corba.
>
> - We're working on bringing Environments Access back from the CLtL2
> grave, and will eventually contribute it to opensource.
But isn't this a little bit of damning with faint praise? Given that
people in this newsgroup are asking for five or six different areas of
standardization, you've done one and one-half, and none of the major
ones that people are asking for. Note that I don't blame you for
this. I'm sure that if your paying customers were asking for it, you
would have done more in that way.
> - One of my colleagues is the chair on the NCITS (the body that
> carries on the work of what the X3J13 committee originally did).
> It is interesting that people blame vendors for not being interested
> in standards; when the rubber meets the road (i.e. you have to pay
> yearly dues), very few people are signed up on that committee.
I don't say that vendors are not interested in standards. In fact,
vendors have a vested interest in the process, because it will affect
them most closely. Clearly Franz believes from a business perspective
that paying these dues and devoting this time to the NCITS is not a
waste. Again this isn't cynical at all.
>
> > If standardization were such a good thing for
> > vendors, they would have pushed for it.
>
> Right, absolutely :-)
>
> > In fact, though, vendors are
> > traumatized by standardization (unless they can get their
> > implementation of everything to be the standard).
>
> I am not in a position to say whether this is true or not, since
> many of the standards (in as many senses of the word "standard" as
> you care to consider) which we work on are backed by our own
> implementations. But this is an unfortunately cynical point
> of view. Perhaps Microsoft _has_ won, after all; their business
> style has captured the hearts and minds of programmers everywhere.
I didn't intend to be cynical. I was actually trying to make the case
for legitimately not expecting vendors to do everything in advancing
the standardization process.
But I believe that I am correct, from a historical perspective, when I
say that the standardization process is traumatic. For example, when
the DARPA (or was it ARPA) 700 lb. gorilla forced vendors to
standardize on Common Lisp, the process ended up pretty much blowing
Interlisp completely out of the water. Franz, too, struggled with the
process, or so I hear from someone who has read the transcripts of the
meetings.
--
-Fred Gilham gil...@csl.sri.com
"In America, we have a two-party system. There is the stupid
party. And there is the evil party. I am proud to be a member of the
stupid party. Periodically, the two parties get together and do
something that is both stupid and evil. This is called --
bipartisanship." --Republican congressional staffer
Erann Gat
wrote:
> On Fri, 07 May 2004 11:02:12 -0700, Erann Gat <gNOS...@flownet.com> wrote:
>
> > In article <m3pt9g2...@javamonkey.com>,
> > Peter Seibel <pe...@javamonkey.com> wrote:
> >
> >> Erann Gat <gNOS...@flownet.com> writes:
> >>
> >> > Sockets. Threads. Database. Regular expressions. These are
> >> > the Big Four that Lisp is lacking IMO.
> >>
> >> So I'd suggest that Edi's CL-PPCRE knocks off regexps.
> >
> > No, it doesn't. For one thing, it doesn't work in the latest
> > version of MCL.
>
> So, if regular expressions are so important, as you said earlier in
> this thread, why didn't you report that?
I just did. I presume what you meant to ask was why I didn't report it
earlier. The answer is because I didn't know earlier.
> If I'm not mistaken the only problem is that Digitool hasn't yet
> realized that OS X is Unix.
That does appear to be the proximate cause of CL-PPCRE not running on
MCL.
> If you see other errors or if your version
> of MCL differs significantly from the trial version that can be
> downloaded please feel free to send a bug report and I'll do what I
> can.
>
> Of course it's more fun to bitch on c.l.l. :)
I'm sorry, my intent here was not to bitch about CL-PPCRE, which does
indeed appear to me to be a fine product. The topic at hand is
standardization.
The community keeps going around and around on this. The argument
always goes the same way. Someone points out that the CL standard is
missing X, Y and Z and wouldn't it be great if this were not the case,
and someone else responds by saying, "But you can get X, Y and Z by
simply doing P, Q and R." There are two problems with this. First, it
very often turns out that to get X, Y, and Z you not only have to do P,
Q and R, but A and B and C and D and E and F and G as well. The
CL-PPCRE example is a perfect example. You had to list nine steps you
had to go through to get it to work, and at the end you conclude with
"Now only four or five unexpected errors remained."
Even if in retrospect getting it to work was not very hard, that doesn't
really matter. What matters more is the a priori expectation that it
can be made to work without having to expend a huge amount of effort.
One has to have a reasonable expectation that it will be easier to use
someone else's code than it will be to write their own in order for it
to be rational to even try. The situation in Common Lisp stands in
stark contrast to the situation in e.g. Perl or Python. If you download
a Python module from python.org the probability is very high that it
will Just Work. If you download some Lisp code from somewhere (there is
no Lisp equivalent of python.org or CPAN) the chances that it will Just
Work are, in my experience, close to zero, especially if you are using a
different Lisp than the version the code was originally written for, and
double especially if the code does anything requiring interaction with
the outside world.
(Another effect of Lisp's fragmentation is that to get X to work you
first have to locate, download, and debug several other packages,
notably defsystem and/or asdf, and uffi.)
Now, some people in the Lisp community take the position that anyone who
is too lazy to do a little debugging ought not to be using Lisp in the
first place. That is a defensible position, but the consequence is that
the size of Lisp's potential audience is reduced, because it doesn't
take a whole lot of discouragement to get someone to walk away from
Lisp. Lisp elitists think that's OK. Personally, I am of the opinion
that the world would be a better place if Lisp were more popular. On
this matter the different camps may have to agree to disagree.
But IF you agree that making Lisp more popular would be a good thing,
then I think you ought to support the development of some sort of
process to somehow semi-officially enshrine incremental changes to the
standard. The mere development of more open source will not and cannot
address the unmet needs that IMO present a significant barrier to Lisp's
more widespread use. It doesn't have to be ANSI. It doesn't have to be
expensive. SRFI's I think make a good model. All this was discussed at
the last Lisp conference, but it seems to have gone nowhere.
E.
Erann Gat
Peter Seibel <pe...@javamonkey.com> wrote:
> Erann Gat <gNOS...@flownet.com> writes:
>
> > In article <m3pt9g2...@javamonkey.com>,
> > Peter Seibel <pe...@javamonkey.com> wrote:
> >
> >> Erann Gat <gNOS...@flownet.com> writes:
> >>
> >> > Sockets. Threads. Database. Regular expressions. These are the Big
> >> > Four that Lisp is lacking IMO.
> >>
> >> So I'd suggest that Edi's CL-PPCRE knocks off regexps.
> >
> > No, it doesn't. For one thing, it doesn't work in the latest version of
> > MCL. And, very much to the point, it is not clear whether the reason it
> > doesn't work is a bug in CL-PPCRE or a bug in MCL.
> >
> > But even if CL-PPCRE worked perfectly I would still argue that it
> > does not serve the same purpose that a standard would. If this were
> > not the case then standardizing CLOS serves no purpose given the
> > existence of PCL. For that matter, one could argue that there is no
> > point in standardizing anything at all, including Common Lisp
> > itself, as long as a portable implementation exists.
>
> Okay. I agree. I overstated the case when I said it "knocks off
> regexps". It is *not* a standard. What I was really trying to suggest
> is that we have what could very well be the *basis* for a standard in
> the form of a high-quality, widely-ported, documented implementation
> of a reasonable API.
Yes, I certainly agree with that. We have no shortage of raw material
for possible new standards. What we as a community do not have is a
process by which we can take those potential standards and turn them
into actual standards.
> I.e. all we have to do is *agree* that this is
> the way to do regexps and we're done. Not that that last step is a
> necessarily a small one. But at least step one isn't, "Collectively
> design a regexp API on c.l.l." <shudder>.
Yes. It is that simple. And that complicated.
> The question for those of us--and I count myself as one--who think
> Common Lisp would benefit from some more standards, probably de facto,
> layered on top of the fine language standard we already have is what
> would it it take for CL-PPCRE to actually become the "standard" way to
> do regexps in Common Lisp?
Yes, that is a question that I think the community would benefit from
giving some serious thought to.
> Indeed, that last bit seems to me to be the crux of the matter. What
> has to happen before "the community can speak with a single voice" on
> the question of how to do regexps in Common Lisp? I don't imagine 100%
> of Common Lispers could every agree on anything and there are no
> law-giving bodies that are in a position to start laying down the law.
> But if enough people treat CL-PPRCE as the answer to the question,
> "How do you do regexps in Common Lisp?" then that might be close
> enough.
Yes, that is one possible process: wait around and see what ends up
getting used. But that is essentially the process that's been in use
for over a decade now and it doesn't seem to be particularly effective
from where I sit.
> If every new Lisper who asks about regexps is told to use CL-PPCRE,
> vendors who care about selling their product to those new programmers
> will either make sure they don't break CL-PPCRE on their impls or will
> send Edi patches. Of course if they don't care about the emerging de
> facto standard they will ignore it. Of course there are current Common
> Lisp implementations that claim to be conformant which ignore certain
> parts of the de jure language standard we already have.
What if, God forbid, Edi gets hit by a bus?
> Given that Edi has done most of the heavy lifting, my point is if at
> least those folks who think there *should* be a de facto regexp
> standard can't agree to agree that CL-PPCRE is the answer and move on
> then there is little liklihood of there ever being a de facto standard
> for something as complex as a threading or networking API.
That depends on what process you use to decide on new standards. It
doesn't have to be consensus-based. If it did, ANSI-CL would never have
happened.
In fact, the sort of anarchic process in place today is precisely the
same process that was in place before consensus was abandoned in favor
of something else, which produced ANSI-CL (and it's leading to very
similar results).
> [1] I imagine you'll want to send Edi a bug report about the problem
> with the latest MCL and get it fixed before you'll agree to promote
> CL-PPCRE. But I can't imagine that's a complete showstopper given that
> Edi has expressed an interest in such a bug report.
You're missing the point. The particular bug in CL-PPCRE (which is
arguably a bug in MCL) is irrelevant. What matters is the process (or
lack thereof) by which standards are arrived at -- or not arrived at as
the case may be.
E.
niko...@random-state.net
> more widespread use. It doesn't have to be ANSI. It doesn't have to be
> expensive. SRFI's I think make a good model. All this was discussed at
> the last Lisp conference, but it seems to have gone nowhere.
The merits of SRFI are, I hope, well known. It's major flaw (which may or
may not be relevant for Scheme, but IMO certainly is for CL), is that there
is no real quality control: any formally correct SRFI will pass unless it's
author withdraws it. The "commmunity (or reperesantatives thereof) accepts
it" step...
By the by, thanks you for putting up the locale.lisp and co. While hacking
on package-related code I've been thinking on and off about module systems,
so I found your locale implementation especially interesting.
Cheers,
-- Nikodemus
Tayssir John Gabbour
> - One of my colleagues is the chair on the NCITS (the body that
> carries on the work of what the X3J13 committee originally did).
> It is interesting that people blame vendors for not being interested
> in standards; when the rubber meets the road (i.e. you have to pay
> yearly dues), very few people are signed up on that committee.
Ahh... so THAT'S where I came across this quote:
"4. Expected Challenges
"... Segments of the lisp community tends toward vehemence and
language fundamentalism; managing this during a project to alter the
sacred writ of the ANS may be a problem."
http://www.franz.com/~smh/J13/03-001.htm
--
"Why is it so difficult to find SDO members from an active language
community? Several causes can be suggested:
" * J13 has no active projects. The community from time to time
expresses vague interest in new standards work -- "It would be nice
if..." -- but there is no momentum from which J13 can draw.
" * Even large players in the computer industry are financially
stressed. A number of interested former members were simply unable to
obtain management approval for something with no demonstrable,
short-term benefit. Further, some members of the community are
independently employed, or under employed, and it is hard to justify
expense of $800 in personal funds where there is no manifest financial
return.
" * Finally, there is competition from other forms of
standardization. If you think about it, the open source movement
competes with formal SDO activity. While open source is not quite the
same as standardization, it fills many of the same needs: It provides
a forum for negotiation of details; It provides automatic publication
of the result; and achieves community conformance to a common
practice. In addition, open source has the benefit of being
more-easily capable of both rapid change and gradual evolution."
http://www.franz.com/~smh/J13/02-001.htm
Wade Humeniuk
>
> The community keeps going around and around on this. The argument
> always goes the same way. Someone points out that the CL standard is
> missing X, Y and Z and wouldn't it be great if this were not the case,
> and someone else responds by saying, "But you can get X, Y and Z by
> simply doing P, Q and R." There are two problems with this. First, it
> very often turns out that to get X, Y, and Z you not only have to do P,
> Q and R, but A and B and C and D and E and F and G as well. The
> CL-PPCRE example is a perfect example. You had to list nine steps you
> had to go through to get it to work, and at the end you conclude with
> "Now only four or five unexpected errors remained."
But Erann you are guilty about what you are complaining about. The code
you just posted needs your utilities.lisp file which has non-standard
code like define-class and define-method. Why did you not just stick
to the standard and write some stuff which needs R, S and T instead?
I far as I can see much that is in utilties.lisp can be pretty much be
done with standard Lisp. What's with eq?, strcat, fn?
You seem to have problems staying within the current standard for
simple straight forward things. One has to uphold the current standard
to expect compliance with future extensions.
Wade
Tayssir John Gabbour
> condition system:
>
> http://lists.tunes.org/archives/tunes/2001-February/003058.html
>
> The original message looks like it is over 5 years old. I found the
> recommendations to be right on the money.
You might be interested in
http://www.franz.com/~smh/J13/99-010.txt
(Taken from http://www.franz.com/~smh/J13/ ; nothing else on this last
page seems particularly interesting, outside of what I quoted in my
response to Duane earlier in this thread.)
Rob Warnock
+---------------
| The good thing about Common Lisp and its ANSI standard is that it is
| mainly derived from decades of actual programming experience with Lisp
| dialects. So this standard is a unique example of things that weren't
| designed and then forced upon a community without actual experience, but
| just the other way around: Lisp programmers identified common idioms and
| agreed upon compromises between mostly superficial differences.
<RANT>
Actually, this is the way *ALL* standards used to work, up until
around 1980 or so!!! Until then, the assumption was that you didn't
try to "standardize" something until there was enough experience to
know what was good and what was bad, and then you tried to standardize
the "best current practice" or some reasonable compromise thereof.
But then something happened, I'm not quite sure what. Suddenly the
default modus operandi became "design by standards committee", with
the principle of "maximum mutual disadvantage" being enforced so
that no-one who *already* had a decently-working system would have
an "unfair" advantage over others on the committee. And as a result,
we got monstrosities like FDDI/LMT/CMT/SMT and ATM/UNI/LANE and the
growing alphabet soup of web "standards" (which mainly seem designed
to keep anyone with less than a billion dollars out of the game
entirely).
The last decently-spare standards based on *working* technology,
at least in the networking protocols area, were probably Ethernet
(and it just *barely* escaped being broken incompatibly by IEEE 802.3!)
and HIPPI, and maybe IEEE-488 (the standardization of HP-IB).
</RANT>
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
David Steuber
> I'm not advocating standardizing xml-foo, soap-in-a-.net-quux
> etcetera. There's many flavours of the month in other languages which
> are already on the decline by the time the ink's dry on the standard,
> and I don't want a language overburdened with cruft that didn't stand
> the test of time. But some things, such as international language
> support, networking &c, are here to stay and have been with us long
> enough that sensible people can agree on an API.
If they can agree on an API, I wish they would get on with it.
Threads and networking are important to me. Until they do, I will be
using sb-thread and sb-bsd-socket on Linux. I haven't looked at what
OpenMCL has on the Mac. I know that it supports threads though. And
sockets. A new version has just been released and I'll be seeing if
Darwin Ports has it soon.
Odds are that I won't go lower level than library development. That
really wants a portable set of APIs to make things easier.
Application development can use portable APIs as well, but
applications don't necessarily need to be as portable as libraries
do.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Duane Rettig
> > > I think you can see this by looking at the actual behavior of Lisp
> > > vendors. Franz, for example, has certainly not kicked around and
> > > trampled on the idea of standardization --- they even put forth the
> > > "simple streams" proposal.
> >
> > Note that this falls under your "their own implementation as standard"
> > category, below. Also included in this are a number of opensource
> > modules, such as AllegroServe, from which Portableaserve is built, as
> > well as several other modules at http://opensource.franz.com.
> >
> > > But that's about it from what I know.
> > > They haven't tried to push for much else in the way of
> > > standardization.
> >
> > Well, let's see now:
> >
> > - We worked with the other major CL vendor at the time (Harlequin,
> > now Xanalys) to create an official Lisp binding for Corba.
> >
> > - We're working on bringing Environments Access back from the CLtL2
> > grave, and will eventually contribute it to opensource.
>
> But isn't this a little bit of damning with faint praise? Given that
> people in this newsgroup are asking for five or six different areas of
> standardization, you've done one and one-half, and none of the major
> ones that people are asking for. Note that I don't blame you for
> this. I'm sure that if your paying customers were asking for it, you
> would have done more in that way.
I think you misunderstood what I said about being self-serving.
I had meant that talking too much about all that we do here is
self-promotional (read: sales/marketing) and that is repulsive
to me. But note that you counted one-and-one-half standards,
and I counted three (remember to include your mention of
simple-streams) plus several I mentioned later.
But the real problem here is what each person reading this thread
thinks of when he sees the word "standard". Sometimes the same
person considers many different things to be standard, at various
times in the thread, and it is as impossible to capture completely
as it is for one person to deflate a fully-spread-out air mattress;
when he sits on one end the other end goes up, and when he sits on
the other end the original end goes up, and the goal of getting the
air out of the mattress is not met.
Let me go into a self-serving mode for an example or two, so that
you can see what I mean:
1. People here have asked for a standard Foreign-Function Interface.
But I believe (and some users have analyzed it and have agreed with
this) that the Allegro CL FFI is one of the best and most complete
FFIs available. So why doesn't everybody just use Franz's FFI
definition? (I know the answer to this, but I place it out there
for people to think about anyway).
2. People have asked for a standard MultiProcessing definition.
But there has always been a "de-facto standard" [*], which has been
the Lisp Machine definition. Unfortunately, this definition makes
certain assumptions about the implementaions of procecess, about
concurrency, and about control aspects, which make such a standard
unusable in today's competitive GP-hardware market (I am not talking
about competing between Lisp vendors, but between Lisp vendors and,
say, MS or Linux/Posix definitions of MultiProcessing). For example,
one aspect of the stack-groups implementations of MP is that one can
run a lisp function to determine if the thread it is associated
with should be woken up. But when working in an os-threads system,
this does not make sense; the lisp function needs to have its thread's
context in order to run, so the operating system must schedule the
thread in order to run the function in order to determine whether
to schedule the thread or not! What happens if the runnable-p
function returns nil? We've just scheduled a thread for the purpose
of determining that the thread shouldn't be scheduled! This does
not play well with non-lisp systems, which tend to do things on
a semaphore or message-passing basis. We at Franz have reworked
our MP system for Allegro CL 7.0 in such a way that it plays
better with underlying operating systems, and have cleaned things
up in such a way that we think will be robust enough to become
standardizable. (we've kept most of the previous interfac, of
course, for back-compatibility, but users will find that the
recommended style will work much more efficiently than the Old
Way).
(Coming back out of self-serving mode):
[*] (3.) People will react to the term "de-facto standard" by saying
that it's not good enough; that what is really needed is a formal
standard. And yet there is very little interest in a formal standard,
as can be seen by counting the number of paid members on the CL
standards committee. Now, we've had this discussion several times
before, and there have lately been several efforts to create new
less-heavyweight standards, but each has its own problems. The
major problem is that a standard is only as good as its acceptance.
And for those who don't accept Reference Implementations or Informal
Standards as a form of standard, such efforts will always be a
sticking point.
Bottom line: a standard is really an agreement, formalized in some
agreed-upon way. Two people might agree and formally declare that
something is a standard; if a third party steps in and says "I don't
agree with this" then that makes it no less a standard, but simply
not a standard with a high degree of acceptance.
> > > If standardization were such a good thing for
> > > vendors, they would have pushed for it.
> >
> > Right, absolutely :-)
> >
> > > In fact, though, vendors are
> > > traumatized by standardization (unless they can get their
> > > implementation of everything to be the standard).
> >
> > I am not in a position to say whether this is true or not, since
> > many of the standards (in as many senses of the word "standard" as
> > you care to consider) which we work on are backed by our own
> > implementations. But this is an unfortunately cynical point
> > of view. Perhaps Microsoft _has_ won, after all; their business
> > style has captured the hearts and minds of programmers everywhere.
>
>
> I didn't intend to be cynical. I was actually trying to make the case
> for legitimately not expecting vendors to do everything in advancing
> the standardization process.
But vendors can't do it alone! Vendors provide implementational
sanity checks in any standards effort. But it is the users who are
the driving force behind any formal standard. If users don't push it,
it doesn't tend to get done.
> But I believe that I am correct, from a historical perspective, when I
> say that the standardization process is traumatic. For example, when
> the DARPA (or was it ARPA) 700 lb. gorilla forced vendors to
> standardize on Common Lisp, the process ended up pretty much blowing
> Interlisp completely out of the water. Franz, too, struggled with the
> process, or so I hear from someone who has read the transcripts of the
> meetings.
A formal standard is traumatic for everyone; it costs a lot of money,
time, and resources, and the trauma is not limited to vendors. I
personally believe that it is the users who are more traumatized; the
vendors already know how hard the process of agreement is, but each
user tends to be shocked that not everyone agrees with him...
Peter Seibel
Right. So what we need is a standard process for devising standards. I
say that only half tounge-in-cheek. Suppose I propose a process for
defining standards. What happens if no one but me thinks it's a good
process? Well then any "standards" it produces will be ignored. So how
do we agree on a process? I don't know. But it seems to me that if we
(where "we" is the people, including myself, who think it might be a
nice thing if there was a de facto standard library for using regexps
in Common Lisp) can't agree to always answer, "CL-PPCRE", when newbies
ask what regexp library to use then I doubt we'll be able to agree on
an abstract process for producing standards. If we can agree on that,
then we can move forward with doing other things that will promote
CL-PPCRE as a defacto standard--encouraging implementors to include it
in their distributions; helping Edi iron out any wrinkles that make it
unusable or too-hard to use in certain circumstances.
I realize this is paradoxical--I am in fact proposing a process for
producing standards and hoping someone, you for instance, will just
agree to it. Be that as it may, it seems like a good idea to head off
the infinite regress sooner rather than later. No matter how you slice
it, if what we actually want is a (de facto) standard regexp library
then we need a critical mass of folks to agree on *two* things--a way
to promulgate such a standard and a library to then standardize. I'm
proposing an answer to each question. I'm fairly confident that
CL-PPCRE is the right answer to the second question; I'm less
confident about my answer to the first but it seems good enough to be
worth a try.
>> I.e. all we have to do is *agree* that this is
>> the way to do regexps and we're done. Not that that last step is a
>> necessarily a small one. But at least step one isn't, "Collectively
>> design a regexp API on c.l.l." <shudder>.
>
> Yes. It is that simple. And that complicated.
>
>> The question for those of us--and I count myself as one--who think
>> Common Lisp would benefit from some more standards, probably de facto,
>> layered on top of the fine language standard we already have is what
>> would it it take for CL-PPCRE to actually become the "standard" way to
>> do regexps in Common Lisp?
>
> Yes, that is a question that I think the community would benefit from
> giving some serious thought to.
>
>> Indeed, that last bit seems to me to be the crux of the matter. What
>> has to happen before "the community can speak with a single voice" on
>> the question of how to do regexps in Common Lisp? I don't imagine 100%
>> of Common Lispers could every agree on anything and there are no
>> law-giving bodies that are in a position to start laying down the law.
>> But if enough people treat CL-PPRCE as the answer to the question,
>> "How do you do regexps in Common Lisp?" then that might be close
>> enough.
>
> Yes, that is one possible process: wait around and see what ends up
> getting used. But that is essentially the process that's been in use
> for over a decade now and it doesn't seem to be particularly
> effective from where I sit.
Well, I'm suggesting something a bit more active than just waiting
around. If you agree with me that CL-PPCRE is the nearest thing to a
standardizable regexp library (i.e. it is of high-enough quality, it
is licensed in a way that would allow it to be used in both open
source and commercial projects, and it has been ported (with more or
less success) to virtually every currently available Common Lisp
implementation) then we should then think about what we can do to
encourage people to consider it The Way to do regexps. I can think of
a bunch of stuff that an individual could do--help Edi, recommend it
here, put glowing testimonials on Cliki, request your vendor support
it. (You're a paying MCL customer, right? So they should at least be
interested if you tell them that you would find their product more
valuable if it shipped with CL-PPCRE built in.) And perhaps most
important, if you think CL-PPRCE is in fact the right answer and
*should* be the de facto standard then *say* so when someone shows up
in c.l.l. asking how to do regexps in CL rather than telling them
there is no standard way and never will be until our fractious
community can first agree on a method for producing standards. Which
is not to say you have to lie to them--it seems fine to say:
There's no official standard and there are a number of different
implementations including several provided by different Lisp
implementors. However the CL-PPCRE library available at
<http://www.weitz.de/cl-ppcre/> is an extremely fast, pure Lisp
implementation of a Perl compatible regexp engine that runs on
almost every current Common Lisp implementation and is on its way to
becoming the de facto standard Common Lisp regexp library.
To the extent that more people agree with you (or stay silent) and
fewer pipe up to contradict you, this will become a self-fulfilling
prophecy.
>> If every new Lisper who asks about regexps is told to use CL-PPCRE,
>> vendors who care about selling their product to those new programmers
>> will either make sure they don't break CL-PPCRE on their impls or will
>> send Edi patches. Of course if they don't care about the emerging de
>> facto standard they will ignore it. Of course there are current Common
>> Lisp implementations that claim to be conformant which ignore certain
>> parts of the de jure language standard we already have.
>
> What if, God forbid, Edi gets hit by a bus?
His code is pretty clean from what I've seen. I think it will survive
him in that tragic eventuality. Especially if there are people who
think it's worthwhile. Heck, if Edi gets hit by a bus *I'll* probably
maintain it, if only for my own selfish reasons. In other words, if
his code wasn't valuable enough to expect that someone else would pick
up the ball if he abandons it for whatever reason, then it's probably
not ripe to become de facto standard.
>> Given that Edi has done most of the heavy lifting, my point is if
>> at least those folks who think there *should* be a de facto regexp
>> standard can't agree to agree that CL-PPCRE is the answer and move
>> on then there is little liklihood of there ever being a de facto
>> standard for something as complex as a threading or networking API.
>
> That depends on what process you use to decide on new standards. It
> doesn't have to be consensus-based. If it did, ANSI-CL would never
> have happened.
Actually I think the history of Common Lisp, at least pre-ANSI, is
quite instructive and inspirational. As I understand it (and I am no
doubt grossly condensing and simplifying the actual history) various
folks who were using Common Lisp agreed there was a problem (in that
case that DARPA was going to get fed up with the proliferation of Lisp
dialects and stop funding them) and decided to get a small group of
people together to see if they could agree on what a unified language
could look like. While plenty of people were ultimately invited into
the process (and some of them then ignored) the main proposal was put
together by a fairly small group of self-appointed folks. Eventually
enough folks got on board that the fruits of their labor were then in
a good position to be more widely adopted and eventually picked up by
a formal standardization process.
Or for another, much-cited, example take the RFC's that "specify" how
the internet works. As no doubt you know, some folks who needed to
agree on some stuff so they could get work done figured that while
they were waiting for the "people in charge" to show up and start
telling them how things should really work they could write up some
ideas and see if other folks would agree in the interest of moving
forward. Which was a good thing because the "people in charge" never
showed up. I think were in a similar situation today with Common
Lisp.
> In fact, the sort of anarchic process in place today is precisely
> the same process that was in place before consensus was abandoned in
> favor of something else, which produced ANSI-CL (and it's leading to
> very similar results).
So the folks who care need to step up and propose answers to the
questions that they feel need better answers. The need may be less
pressing this time around since there's no big entity like DARPA
threatening to cut off all of our funding if we don't figure it out
but I don't see why a similar solution won't work.
-Peter
Marc Spitzer
> Wade Humeniuk wrote:
>> Cameron MacKinnon wrote:
>>
>>>
>>> Why are you willing to use apparent mediocrity in other computer
>>> languages as an excuse for API fragmentation in CL? Is "just as
>>> good as other languages" what drew you to CL? Is it what you think
>>> CL should aim for?
>>>
>> You have not answered my question. Why are you holding up CL to
>> a different standard (and thus the people around it)?
>
> What is this "different standard"? People coding in Java don't have to
> worry about the idiosyncrasies of their vendor's network API or
> threads API. Java is not a single implementation language. I'm sure
> you can think of plenty of similar examples.
umm have you notices that *dam near every* java app that ships comes
with its own java run time. It seem that no vendor will trust java to
work with their app unless they ship the *exact* version of java they
wrote it against. And all this mess only happened in the last 5-7 years.
>
> CL certainly isn't the only language whose users have cried out for a
> single API to address these (and other) things. Other languages have
> delivered. So I'm not holding CL to a higher standard than others have
> held other languages to.
the other languages generally only have one authoritative
implementation, perl, python, tcl, ruby ..., so they by definition are
basically compatible *with them selves* and this is not true across
time, just for a point in time represented by version x.y.z.
>
>> Your implication is that it is a superior language, thus it
>> has to have single monolithic authoritative standard libraries.
>
> Well, I don't want you to be confused by my subtle implications, so
> I'll spell it out. ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL
> PURPOSE YET HAS NO STANDARD NETWORK API IS INFERIOR IN THAT RESPECT,
> AND INDEED BLIGHTED. Do you disagree?
So C is not good enough to do "real work in", if you are curious take
a look at qpopper's source code for the network bits. Each network
access function was written 1 time for *EACH* unix it supported and
was compiled in via #ifdef's. But above that level the api was the
same so after your done with the socket code it ain't a problem any
more. And if you want to add a new unix just add the compatibility
layer and you are pretty much done.
>
>> Sorry, but that is ridicdulous. I am sorry you are disappointed with the
>> "other" languages and are putting your unrealistic hopes on
>> CL.
>
> Is there something specific about the CL community that makes my hopes
> unrealistic? Because other languages have standardized these things,
> and other languages have ongoing standardization processes. Why do YOU
> hold CL to a lower standard in this regard?
To be perfectly honest I don't give a shit about your hopes. I care
about your actions/statements and they are hostile. You are holding
this language up to a higher standard then other languages and then
using the fact that CL does not pass your much harder test to say that
it is inferior to languages that you did not even bother to grade against
this higher standard. And because of your one sided sniping evaluation
you claim that CL has failed compared to python, for example. When the
simple fact you are not engaging in honest pursuit of the truth.
Get a job with CNN and spew there.
marc
Wade Humeniuk
>
> Let me go into a self-serving mode for an example or two, so that
> you can see what I mean:
>
> 1. People here have asked for a standard Foreign-Function Interface.
> But I believe (and some users have analyzed it and have agreed with
> this) that the Allegro CL FFI is one of the best and most complete
> FFIs available. So why doesn't everybody just use Franz's FFI
> definition? (I know the answer to this, but I place it out there
> for people to think about anyway).
>
> 2. People have asked for a standard MultiProcessing definition.
> But there has always been a "de-facto standard" [*], which has been
> the Lisp Machine definition. Unfortunately, this definition makes
Just for the record, though I have not used your FFI
from my understanding of it I consider it to be the best out there.
Allocation types are great.
http://www.franz.com/support/documentation/6.2/doc/ftype.htm#allocation-types-1
If it ever did come to some kind of vote for Franz's FFI to become
standard you would get my aye! Just one thing though, better FFI to C++,
name-mangling is a pain. (There is an idea for a library, converting
C++ definitions to name-mangled linker names for use by the current
FFI implementations, platform and compiler dependent of course).
Wade
Friedrich Dominicus
> (one "require" statement at most,
> without having to load "asdf" or some other crud), or those packages be
> used as the starting point for standardization efforts for those
> facilities.
Why is it ok to have a lot of tools in the Unix/Shell/C development
which have to play together nicely to get you program going. So
explain why do we have the automake+autoconf tools but why is it not
ok to have to load asdf?
> I think there are some features that have progressed to that
> point. Perhaps not UI (probably not ever) and perhaps not code dependency
> management, but multiprocessing, foreign function interfaces, and socket
> interfaces have reached that point, just as file system interfaces had 20
> years ago and memory management 40 years ago.
Why do you think file system interfaces are standard? I know just one
language which tries to offer a common interface. Others have simply
followed the Unix conventions and do not even care about a file system
interface. Now to the different things you think are now standard.
- multiprocessing. Well you can have a look at CL-HTTP or
PortableAllegroServe and you'll find a common interface there. What's
you problem using it?
- FFI now there does exist UFFI, which seems to be good enough. What
prevents you from using it?
- socket interface. Again feel free to use the existing libraries as
base.
If you do not want do that yourself. Go to www.franz.com, or
www.lispworks.com and buy it all in one package, or feel free to
sponsor the development of "the" portable packages you want to have.
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Friedrich Dominicus
> Even if in retrospect getting it to work was not very hard, that doesn't
> really matter. What matters more is the a priori expectation that it
> can be made to work without having to expend a huge amount of effort.
> One has to have a reasonable expectation that it will be easier to use
> someone else's code than it will be to write their own in order for it
> to be rational to even try. The situation in Common Lisp stands in
> stark contrast to the situation in e.g. Perl or Python. If you download
> a Python module from python.org the probability is very high that it
> will Just Work. If you download some Lisp code from somewhere (there is
> no Lisp equivalent of python.org or CPAN) the chances that it will Just
> Work are, in my experience, close to zero, especially if you are using a
> different Lisp than the version the code was originally written for, and
> double especially if the code does anything requiring interaction with
> the outside world.
Well that is a point which has driven me mad more than once, I second
that. But the problem is that even if you use the same Lisp that it
seldom works, and even more seldom is some kind of
documentatation. Hey Luke use the code is probably the answer to it
all. But code is not documentation...
>
> Now, some people in the Lisp community take the position that anyone who
> is too lazy to do a little debugging ought not to be using Lisp in the
> first place. That is a defensible position, but the consequence is that
> the size of Lisp's potential audience is reduced, because it doesn't
> take a whole lot of discouragement to get someone to walk away from
> Lisp.
I hardly can agree more. I feel not overly happy to debug code into
running, unfortunatly I have made this experience in Common Lisp more
often than elsewhere.
>
> But IF you agree that making Lisp more popular would be a good thing,
> then I think you ought to support the development of some sort of
> process to somehow semi-officially enshrine incremental changes to the
> standard. The mere development of more open source will not and cannot
> address the unmet needs that IMO present a significant barrier to Lisp's
> more widespread use. It doesn't have to be ANSI. It doesn't have to be
> expensive. SRFI's I think make a good model. All this was discussed at
> the last Lisp conference, but it seems to have gone nowhere.
Well the point is many here are blaiming Scheme to be a poor man's
Lisp or even dispute that Scheme is a Lisp. And we do like to point
out how much thicker our standard is...
Happy hacking
Friedrich Dominicus
> Erann Gat wrote:
>
>
> But Erann you are guilty about what you are complaining about. The code
> you just posted needs your utilities.lisp file which has non-standard
> code like define-class and define-method.
Well the code is provided or not? And it goes beyond the base
defclass, and well do we have a programmable language or not?
> Why did you not just stick
> to the standard and write some stuff which needs R, S and T instead?
> I far as I can see much that is in utilties.lisp can be pretty much be
> done with standard Lisp. What's with eq?, strcat, fn?
Well I can fully understand if he does not want to write
(concatenate 'string "..." "...") and I bet that everyone has written
some small wrappers about functions more than once. So why shouln't he
have the same right.
This reminds me of the thread about the if* macro. People have flamed
John for even using it... The only thing I disliked about it that it
was claimed it's simply better, and that the standard stuff should not
be used.
>
> You seem to have problems staying within the current standard for
> simple straight forward things. One has to uphold the current standard
> to expect compliance with future extensions.
What does this mean?
Duane Rettig
> Duane Rettig wrote:
>
> > Let me go into a self-serving mode for an example or two, so that
>
> > you can see what I mean:
> > 1. People here have asked for a standard Foreign-Function Interface.
>
> > But I believe (and some users have analyzed it and have agreed with
> > this) that the Allegro CL FFI is one of the best and most complete
> > FFIs available. So why doesn't everybody just use Franz's FFI
> > definition? (I know the answer to this, but I place it out there
> > for people to think about anyway).
> > 2. People have asked for a standard MultiProcessing definition.
>
> > But there has always been a "de-facto standard" [*], which has been
> > the Lisp Machine definition. Unfortunately, this definition makes
>
> Just for the record, though I have not used your FFI
> from my understanding of it I consider it to be the best out there.
> Allocation types are great.
>
> http://www.franz.com/support/documentation/6.2/doc/ftype.htm#allocation-types-1
>
> If it ever did come to some kind of vote for Franz's FFI to become
> standard you would get my aye!
Thanks. It was really a team effort, and brought many implementations
together; when Martin Mikelsons came to us from Lucid after its demise,
he brought a load of expertise on their ffi, and after he had worked
with our Procyon-based lisp and our Unix-based defforeign interface,
and after he had interviewed developers and customers, he came up with
the initial spec for the new interface. Then I refined and implemented
the basic interface and John Foderaro designed and implemented the foreign
types system.
> Just one thing though, better FFI to C++,
> name-mangling is a pain. (There is an idea for a library, converting
> C++ definitions to name-mangled linker names for use by the current
> FFI implementations, platform and compiler dependent of course).
Yes. I'd love to see this be possible. But my understanding (only
indirectly, though, since I haven't seen it myself) is that the C++
spec explicitly discourages vendors from using the same mangling
technique as others. This puts a real pinch on interfacing to it...
I guess ` extern "C" {} ' is your friend, here, unfortunately. I'd
love to see some kind of functionality somewhere (I wouldn't care
what language it was written in, I guess) which mangled and unmangled
C++ names on various platforms. If such library functions were available,
then one could use the conversion function capability of def-foreign-call
to mangle the names for each architecture...
Edi Weitz
> In article <m3pt9g7...@bird.agharta.de>, Edi Weitz <e...@agharta.de>
> wrote:
>
>> So, if regular expressions are so important, as you said earlier in
>> this thread, why didn't you report that?
>
> I just did.
Uttering a sentence like "it doesn't work" in some random public forum
is usually not considered a bug report,[1] at least not by me.
> I presume what you meant to ask was why I didn't report it earlier.
No, I meant what I said.
> That does appear to be the proximate cause of CL-PPCRE not running
> on MCL.
Let me repeat for other people who might be reading this: From my
recent tests with the most current trial version CL-PPCRE /does/ run
fine on MCL after some tweaking related to MCL's strange file
handling. I wonder why you're trying to suggest it doesn't. (Unless
you've seen other errors which I've asked you repeatedly to report.)
FWIW, the next CL-PPCRE release will include special test data and
docs for MCL users.
Cheers,
Edi.
Erann Gat
Wade Humeniuk <whum...@telus.delete.net> wrote:
> Erann Gat wrote:
>
> >
> > The community keeps going around and around on this. The argument
> > always goes the same way. Someone points out that the CL standard is
> > missing X, Y and Z and wouldn't it be great if this were not the case,
> > and someone else responds by saying, "But you can get X, Y and Z by
> > simply doing P, Q and R." There are two problems with this. First, it
> > very often turns out that to get X, Y, and Z you not only have to do P,
> > Q and R, but A and B and C and D and E and F and G as well. The
> > CL-PPCRE example is a perfect example. You had to list nine steps you
> > had to go through to get it to work, and at the end you conclude with
> > "Now only four or five unexpected errors remained."
>
> But Erann you are guilty about what you are complaining about.
I know. If you go back in this thread you will see that I expressed a
certain reluctance to publish this code, and this was one of the reasons.
But -- so what?
> The code
> you just posted needs your utilities.lisp file which has non-standard
> code like define-class and define-method. Why did you not just stick
> to the standard and write some stuff which needs R, S and T instead?
> I far as I can see much that is in utilties.lisp can be pretty much be
> done with standard Lisp. What's with eq?, strcat, fn?
utilities.lisp is a horrid agglomeration of ideas of varying degrees of
merit that have accrued since I started programming in Lisp now nearly
twenty years ago. EQ? for example is a leftover of the days when I was
a T fan. FN is there because I have an obsessive-compulsive aversion to
typing LAMBDA all the time. (Actually, at the time, it was #'(lambda
... because LAMBDA was not then a special form.) DEFINE-CLASS is there
because I can never remember the syntax for DEFCLASS, and because I was
once enamored of Oaklisp. Besides, isn't that supposed to be the whole
point of Lisp, that you can tweak the language to suit your tastes?
Programmable programming language and all that?
But, ironically, utilities.lisp is, as far as I know, portable.
<tangent> One of these days I will get around to implementing the
RDB-based programming environment that I've been planning for years now,
and that will allow me to clean up a lot of legacy cruft. But for now
this is the way my code is, and I don't have time to clean it up. If
you don't like it your money will be cheerfully refunded. </tangent>
> You seem to have problems staying within the current standard for
> simple straight forward things. One has to uphold the current standard
> to expect compliance with future extensions.
Why? It seems to me that the merits of standards (or lack thereof) for
the community ought to be orthogonal to the issue of my private
programming sins.
E.
Erann Gat
niko...@random-state.net wrote:
> Erann Gat <gNOS...@flownet.com> wrote:
>
> > more widespread use. It doesn't have to be ANSI. It doesn't have to be
> > expensive. SRFI's I think make a good model. All this was discussed at
> > the last Lisp conference, but it seems to have gone nowhere.
>
> The merits of SRFI are, I hope, well known. It's major flaw (which may or
> may not be relevant for Scheme, but IMO certainly is for CL), is that there
> is no real quality control: any formally correct SRFI will pass unless it's
> author withdraws it. The "commmunity (or reperesantatives thereof) accepts
> it" step...
I think this is managable. Bad SRFIs will tend not to be implemented or
used. Simply having a centralized location for publishing and
commenting and establishing the nomenclature of proposed standards will
help a lot.
> By the by, thanks you for putting up the locale.lisp and co. While hacking
> on package-related code I've been thinking on and off about module systems,
> so I found your locale implementation especially interesting.
You're welcome. I have no revision control on my code and I've been
hacking on the locales code off and on, so what I put up may very well
be broken. If you have problems with it please let me know.
E.
Erann Gat
wrote:
> On Fri, 07 May 2004 15:36:13 -0700, Erann Gat <gNOS...@flownet.com> wrote:
>
> > In article <m3pt9g7...@bird.agharta.de>, Edi Weitz <e...@agharta.de>
> > wrote:
> >
> >> So, if regular expressions are so important, as you said earlier in
> >> this thread, why didn't you report that?
> >
> > I just did.
>
> Uttering a sentence like "it doesn't work" in some random public forum
> is usually not considered a bug report,[1] at least not by me.
Very well, then it's because between when I first downloaded CL-PPCRE
and when I uttered "it doesn't work" in some random public forum less
than twenty minutes had elapsed, and before I could put together what I
would consider a credible bug report you posted that you already had the
problem fixed.
> Let me repeat for other people who might be reading this: From my
> recent tests with the most current trial version CL-PPCRE /does/ run
> fine on MCL after some tweaking related to MCL's strange file
> handling. I wonder why you're trying to suggest it doesn't.
I am not suggesting any such thing. All I said was that it doesn't work
out of the box, which is true (or at least it was true at the time I
said it). I am not trying to impugn CL-PPCRE, which, as I've said
before, seems to me to be a fine piece of work.
E.
Paolo Amoroso
> regexps". It is *not* a standard. What I was really trying to suggest
> is that we have what could very well be the *basis* for a standard in
> the form of a high-quality, widely-ported, documented implementation
> of a reasonable API. I.e. all we have to do is *agree* that this is
> the way to do regexps and we're done. Not that that last step is a
[...]
> I personally agree to tell everyone I know that CL-PPCRE is how to do
> regexps in Lisp. If you agree there's two of us[1]. And if we can get
> one more, as Arlo Guthrie says, it's a movement.
Me too. I also agree to use and recommend the following:
- ASDF/ASDF-INSTALL for system definition/building
- UFFI for FFI
As I have said elsewhere in this thread, let's put Mr. Darwin at the
controls.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso
> Yes, I certainly agree with that. We have no shortage of raw material
> for possible new standards. What we as a community do not have is a
> process by which we can take those potential standards and turn them
> into actual standards.
Here is the process:
CL-PPCRE is the recommended standard for regular expressions in
Common Lisp.
In Apollo 13, Jim Lovell says something like "let's put Mr. Newton at
the controls". So, let's put Mr. Darwin at the controls and see what
happens. It's better than nothing, and we have not much to lose.
[Peter Seibel]
>> The question for those of us--and I count myself as one--who think
>> Common Lisp would benefit from some more standards, probably de facto,
>> layered on top of the fine language standard we already have is what
>> would it it take for CL-PPCRE to actually become the "standard" way to
>> do regexps in Common Lisp?
>
> Yes, that is a question that I think the community would benefit from
> giving some serious thought to.
No apologies, no excuses, no serious thought: just do it.
> What if, God forbid, Edi gets hit by a bus?
Ask the Maxima maintainers.
Mario S. Mommer
Paolo Amoroso <amo...@mclink.it> writes:
> Here is the process:
>
> CL-PPCRE is the recommended standard for regular expressions in
> Common Lisp.
>
> In Apollo 13, Jim Lovell says something like "let's put Mr. Newton at
> the controls". So, let's put Mr. Darwin at the controls and see what
> happens. It's better than nothing, and we have not much to lose.
And in fact, making the analogy better still[1], he's at the controls
anyway.
>> Yes, that is a question that I think the community would benefit from
>> giving some serious thought to.
>
> No apologies, no excuses, no serious thought: just do it.
What is this? Voices of reason in c.l.l? :-)
---
[1] Although I don't think that CL is a fubaritic lump of hightech in
the process of becoming junk.
Fred Gilham
At the SRI Lisp User's Group :-) we were discussing this standards
issue. Someone made the point that we ought to distinguish between
libraries, such as regexp libraries or the like, and (for lack of a
better word) implementation features, such as FFI or threading.
The distinction is that the standardization process is much easier for
libraries than for these implementation features. That's because for
a library all you need is a piece of reasonably portable code that
everyone agrees to use. Viola[1], instant standard. But
implementation features require that each vendor implement the
feature.
So for example someone mentioned standardizing on Franz's FFI
interface. This is probably a good idea, but clearly it would be
major work for everyone. The developers for each implementation will
have to figure out how to either convert their version of FFI to
Franz's version or build a compatibility layer.
So we (the SRI Lisp User's Group) were thinking that the lisp
community should pick one fairly simple implementation feature and try
to go through the whole process from start to finish with that. We
were thinking about "resources", since this feature requires a tie-in
to the garbage collector to work most efficiently. Also, web
applications can make good use of resources.
The reason for doing this is first to prove that it can be done, and
second to get experience doing it with something that seems relatively
simple.
At any rate a list of implementation features that people seem to want
to be standardized is
1) FFI
2) Threads
3) Sockets
4) Resources
So I suggest that we have two standardization efforts, a library
standardization effort and a feature standardization effort. We
should call the results "Lisp standard libraries" and "Lisp standard
features". For Lisp standard libraries the results of the standard
effort would be a spec for the library and a reference implementation
that obeys the spec. For Lisp standard features the results would be
a spec and an agreement by a set of implementors to implement the
spec.
[1] This is the comp.lang.lisp standard version of "Behold!". :-)
--
Fred Gilham gil...@csl.sri.com
And then [Clinton] turned to Hunter Thompson, of all people, and said
with wholehearted fervor, "We're going to put one hundred thousand new
police officers on the street."
I was up all night persuading Hunter that this was not a personal
threat. -- P. J. O'Rourke
Paolo Amoroso
> Peter Seibel <pe...@javamonkey.com> writes:
[...]
>> I personally agree to tell everyone I know that CL-PPCRE is how to do
>> regexps in Lisp. If you agree there's two of us[1]. And if we can get
>> one more, as Arlo Guthrie says, it's a movement.
>
> Me too. I also agree to use and recommend the following:
>
> - ASDF/ASDF-INSTALL for system definition/building
> - UFFI for FFI
I have changed my signature for comp.lang.lisp. Incidentally, Lisp
book authors and bloggers can do a lot for promoting informal, grass
roots, let's-start-somewhere standards ;-)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp standards (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Erann Gat
Paolo Amoroso <amo...@mclink.it> wrote:
> Erann Gat <gNOS...@flownet.com> writes:
>
> > Yes, I certainly agree with that. We have no shortage of raw material
> > for possible new standards. What we as a community do not have is a
> > process by which we can take those potential standards and turn them
> > into actual standards.
>
> Here is the process:
>
> CL-PPCRE is the recommended standard for regular expressions in
> Common Lisp.
CL-PPCRE is an implementation. An implementation is not a standard.
> In Apollo 13, Jim Lovell says something like "let's put Mr. Newton at
> the controls". So, let's put Mr. Darwin at the controls and see what
> happens. It's better than nothing, and we have not much to lose.
The trouble is that the results of Darwinian processes are rarely
definitive, and they don't provide a good mechanism for dissenting views
to be heard. Accordingly, "standards" selected by Darwinian processes
often have trouble gaining universal acceptance because people who don't
like them feel disenfranchised. For example, I don't like Perl regexp
syntax. I prefer Python syntax, or something more Lispy. When do I get
to have my say?
E.
niko...@random-state.net
Firstly, I applaud to the notion of separating library features from
implementation features. It scales better: if you have user extensible
streams and FFI, sockets can become a library instead of an implementation
feature.
Secondly, I'd like to point out that instead of pointing at a library and
saying "this is now standard" there really should be a step where you
actually ask what "moon on a stick" features does the implementation miss,
and which of those would actually belong in a standard. As in, don't aim
at best (you never get there), good enough (it's only for now), but aim at
"right".
For example, UFFI lacks foeign callbacks, and CL-PPCRE works only on
strings, not arbitrary seqences. I'm not saying either of these is
necessarily required, but unless you think about the issue you _may_ end
up later moaning "This really sucks, I can't use standard regexes with
bit-vectors!".
> to go through the whole process from start to finish with that. We
> were thinking about "resources", since this feature requires a tie-in
> to the garbage collector to work most efficiently. Also, web
Have you been in touch with any implementors -- commercial or otherwise?
Cheers,
-- Nikodemus
a
it?
"Paolo Amoroso" <amo...@mclink.it> wrote in message
...> I have changed my signature for comp.lang.lisp
...
.> Recommended Common Lisp standards (Google for info on each):
Peter Seibel
> Paolo Amoroso <amo...@mclink.it> writes:
>
>> Peter Seibel <pe...@javamonkey.com> writes:
> [...]
>>> I personally agree to tell everyone I know that CL-PPCRE is how to do
>>> regexps in Lisp. If you agree there's two of us[1]. And if we can get
>>> one more, as Arlo Guthrie says, it's a movement.
>>
>> Me too. I also agree to use and recommend the following:
>>
>> - ASDF/ASDF-INSTALL for system definition/building
>> - UFFI for FFI
>
> I have changed my signature for comp.lang.lisp. Incidentally, Lisp
> book authors and bloggers can do a lot for promoting informal, grass
> roots, let's-start-somewhere standards ;-)
Nice! That's *exactly* what I'm talking about.
-Peter
--
Peter Seibel <pe...@javamonkey.com>
Peter Seibel
> In article <87brkz4...@plato.moon.paoloamoroso.it>,
> Paolo Amoroso <amo...@mclink.it> wrote:
>
>> Erann Gat <gNOS...@flownet.com> writes:
>>
>> > Yes, I certainly agree with that. We have no shortage of raw material
>> > for possible new standards. What we as a community do not have is a
>> > process by which we can take those potential standards and turn them
>> > into actual standards.
>>
>> Here is the process:
>>
>> CL-PPCRE is the recommended standard for regular expressions in
>> Common Lisp.
>
> CL-PPCRE is an implementation. An implementation is not a standard.
>
>> In Apollo 13, Jim Lovell says something like "let's put Mr. Newton at
>> the controls". So, let's put Mr. Darwin at the controls and see what
>> happens. It's better than nothing, and we have not much to lose.
>
> The trouble is that the results of Darwinian processes are rarely
> definitive, and they don't provide a good mechanism for dissenting views
> to be heard. Accordingly, "standards" selected by Darwinian processes
> often have trouble gaining universal acceptance because people who don't
> like them feel disenfranchised.
I don't think any standards get universal acceptance. I'm sure there
were folks who were using Lisp around the time of Common Lisp's
standardization who felt disenfranchised by the Common Lisp
standardization process. Some of them eventually decided it wasn't
worth fighting and used Common Lisp anyway. Others may have abandoned
Lisp altogether. And some may still be hacking away in their favorite
pre-Common Lisp dialect because it works for them. The point of the
standard was to get *enough* acceptance by people valued
standardization enough to be willing to yield on certain other issues.
The nice thing about de facto standards is that they are exactly as
strong or as weak as their actual grassroots support.
Also I don't think what I'm proposing is actually a Darwinian process.
At least the way I would draw the analogy between software and natural
Darwinism. That is, I think what we have *now* is more nearly purely
Darwinian--if we think of different libraries and APIs as critters
trying to "survive" and "reproduce" in the evironment that is created
by the sum of all the choices indivdiual Common Lisp programmers make
about what libraries and APIs to use, the fitness function is much
like the fitness function for critters in nature--those that reproduce
(get copied in the case of software) survive; those that don't, die.
What I any standards process does is add a layer of "Intelligent
Design" on top of this Darwinian process. Anyone who buys into a
standards process agrees to rise above the level where individual
libraries are struggling for survival based solely on their merits in
various software niches and communicate with the other participants in
the standards process about their choices, creating an environment
where the libraries and APIs "blessed" by the standards process will
have a better chance of survival due to the coordination made possible
by intelligent communication among. In other words the participants in
the standards process go from being simply "blind" forces of nature to
something akin to gods.
To return to our current problem, regexps, in the current Darwinian
set up, every Lisp developer who uses regexps makes an individual
choice about what library to use. They may take into account such
things as what libraries other people use but there is--as you point
out--no mechanism for people to coordinate those choices. Under this
setup it is theoretically possible that one regexp library will
eventually outcompete all others and become a de facto standard
without any coordination of choices. But as you rightly observe this
doesn't seem to in fact be yielding many de facto standards.
So we need to add a layer of coordination; people have to agree to
choose their regexp library not just on the basis of which one works
best in their own local software niche but with an eye toward
promulgating a de facto standard. I proposed CL-PPCRE as the current
best candidate.
> For example, I don't like Perl regexp syntax. I prefer Python
> syntax, or something more Lispy. When do I get to have my say?
You always have a say. If enough people feel as you do, then CL-PPCRE
will never become a de facto standard. (Though CL-PPCRE already has a
"more Lispy" syntax in addition to its Perl-alike syntax.) Or you can
hop on the CL-PPCRE bandwagon with me and Paolo and then push to add a
Python-alike syntax to CL-PPCRE. But before participating in any
standardization process you have to decide what you're going to do if
certain questions are decided contrary to your own desires.
Or you can find a regexp library that you think is a better candidate
to become the de facto standard and start pushing it the way I'm
pushing CL-PPCRE. (Note, I have no particular reason to support
CL-PPCRE that isn't based on my experiences with using it and other
characteristics that I think make it a good candidate such as its
licensing and the fact that the author seems interested in making it
portable and ammenable to reasonable suggestions about modifications
and enhancements. If someone shows up tomorrow with a clearly better
regexp library I'd be happy to get behind recommending it instead. But
until that happens it seems like promoting and enhancing CL-PPCRE
seems like a more likely route to where *I* want to be.)
Or, if you think it will benefit you and/or the community more, I
suppose you can start working on desiging some other process for
producing standards and see if you can get enough folks to agree that
that's a good way to reach agreement (i.e. get them to agree in
advance to be bound by the decisions reached by following the process)
and then use it to design and promulgate a regexp standard.
I personally have my doubts about whether the later is possible but if
you want to give it a whirl, go for it. Or feel welcome to join Paolo
and me in our agree-to-agree process.
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Dave Roberts
> Why is it ok to have a lot of tools in the Unix/Shell/C development
> which have to play together nicely to get you program going. So
> explain why do we have the automake+autoconf tools but why is it not
> ok to have to load asdf?
I think automake+autoconf is basically a case study for how NOT to do stuff
like this. Frankly, it's an admission that until Linux came around, the
Unix market was messed up and fragmented. Frankly, that's one of the
reasons that Unix never took off as well as it could have: no one
implementation until Linux reached critical mass. There were 3 or 4 main
Unix dialects, each of which had its own peculiarities and generally made
it a royal PITA to port between them. POSIX was the attempt to make things
better. The problem was that POSIX came way too late.
And all that held Unix back. Let's not repeat that fiasco.
> Why do you think file system interfaces are standard? I know just one
> language which tries to offer a common interface. Others have simply
> followed the Unix conventions and do not even care about a file system
> interface. Now to the different things you think are now standard.
That's okay. I mean, just copying one interface generally makes things work.
C has always had a relatively standard interface (open, close, read, write,
seek).
Now, file naming, yes, you're right. That has been a trouble spot. Frankly,
it's a relatively dumb one, too. Think about it: we all keep these linear
streams of bytes called files in hierarchical directory structures, named
by paths from the root, but we can't agree on the character set for each
piece of the path, and we can't agree on the path separator. That's simply
a historical fact of life, but I would argue that it's pretty dumb in
practice.
> - multiprocessing. Well you can have a look at CL-HTTP or
> PortableAllegroServe and you'll find a common interface there. What's
> you problem using it?
>
> - FFI now there does exist UFFI, which seems to be good enough. What
> prevents you from using it?
>
> - socket interface. Again feel free to use the existing libraries as
> base.
>
> If you do not want do that yourself. Go to www.franz.com, or
> www.lispworks.com and buy it all in one package, or feel free to
> sponsor the development of "the" portable packages you want to have.
Yes, *I* can do all that for my code. No issues. Are you going to use all
those same interfaces for your code, so that I can easily use your
libraries, or are you going to pick all manner of
equally-good-but-different compatibility libraries such that when I try to
integrate your code with my code we'll end up with a big conflicting
hairball of a mess that takes time and energy to sort out?
In short, do we want a world that results in us having automake+autoconf, or
do we want to do it right?
--
Dave Roberts, ldave-...@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Dave Roberts
> umm have you notices that *dam near every* java app that ships comes
> with its own java run time. It seem that no vendor will trust java to
> work with their app unless they ship the *exact* version of java they
> wrote it against. And all this mess only happened in the last 5-7 years.
Yes, but... you're identifying a versioning issue, not a portability issue.
That is, I want to ensure that the user is working with JDK 1.X. It isn't
so much a portability problem. I actually have pretty good confidence that
if you write to Sun's JDK 1.4 and you run on IBM's JDK 1.4, you won't have
too many problems. Now, is the system perfect, no. But it's far better than
saying, "Hey, all that portability stuff is just crap. Go wild, people..."
When something doesn't run on one implementation or another, it just means
you have a test escape in your compatibility test suite and you can
identify who is doing it right, who is doing it wrong, and make
corrections.
>
>>
>> CL certainly isn't the only language whose users have cried out for a
>> single API to address these (and other) things. Other languages have
>> delivered. So I'm not holding CL to a higher standard than others have
>> held other languages to.
>
> the other languages generally only have one authoritative
> implementation, perl, python, tcl, ruby ..., so they by definition are
> basically compatible *with them selves* and this is not true across
> time, just for a point in time represented by version x.y.z.
As you point out, there are compatibility problems across versions. That's
always going to be true. And you'll want a FORTRAN 90 compiler to compile
any code written with FORTRAN 90 syntax. So what? We're never going to fix
that problem, but that's a different problem.
> So C is not good enough to do "real work in", if you are curious take
> a look at qpopper's source code for the network bits. Each network
> access function was written 1 time for *EACH* unix it supported and
> was compiled in via #ifdef's. But above that level the api was the
> same so after your done with the socket code it ain't a problem any
> more. And if you want to add a new unix just add the compatibility
> layer and you are pretty much done.
Agreed, but the question is, why should everybody be writing that common
code over and over again? If we agree that it isn't hard to do, then why
don't we just agree on the interface, write it and debug it all once, and
then stick to that higher-level interface?
Thomas F. Burdick
> In article <87brkz4...@plato.moon.paoloamoroso.it>,
> Paolo Amoroso <amo...@mclink.it> wrote:
>
> > Erann Gat <gNOS...@flownet.com> writes:
> >
> > > Yes, I certainly agree with that. We have no shortage of raw material
> > > for possible new standards. What we as a community do not have is a
> > > process by which we can take those potential standards and turn them
> > > into actual standards.
> >
> > Here is the process:
> >
> > CL-PPCRE is the recommended standard for regular expressions in
> > Common Lisp.
>
> CL-PPCRE is an implementation. An implementation is not a standard.
No doubt. It can be the raw material that a standard comes from,
though, or the cannonical library to use.
> > In Apollo 13, Jim Lovell says something like "let's put Mr. Newton at
> > the controls". So, let's put Mr. Darwin at the controls and see what
> > happens. It's better than nothing, and we have not much to lose.
>
> The trouble is that the results of Darwinian processes are rarely
> definitive, and they don't provide a good mechanism for dissenting views
> to be heard. Accordingly, "standards" selected by Darwinian processes
> often have trouble gaining universal acceptance because people who don't
> like them feel disenfranchised. For example, I don't like Perl regexp
> syntax. I prefer Python syntax, or something more Lispy. When do I get
> to have my say?
I don't know. You could try a more Gouldian model, and focus your
efforts at a different competative level, like the standards-making
standard. Or you could insist that any future standard address
certain needs, like s-expression syntax (or POSIX semantics! I mean my
god there *is* already a standard for regexps, which works just fine
for *regular* languages!). I know cl-ppcre already has support for
sexp syntax. I don't know about the state of its introspective and
intercessive facilities, but ensuring its API is flexible enough to
handle the kinds of regexps people want to use would be a step moving
from a good library to a potential spec for a standard.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Lieven Marchand
> But my understanding (only indirectly, though, since I haven't seen
> it myself) is that the C++ spec explicitly discourages vendors from
> using the same mangling technique as others.
It does because otherwise C++ objects compiled with different
compilers would link together but do the wrong time at run time since
they wouldn't agree on all the other details that need to be
determined to implement the C++ object model like layout of classes,
vtables etc.
--
An amateur practices until he gets it right,
A professional practices until she can't get it wrong.
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
>
> > But my understanding (only indirectly, though, since I haven't seen
> > it myself) is that the C++ spec explicitly discourages vendors from
> > using the same mangling technique as others.
>
> It does because otherwise C++ objects compiled with different
> compilers would link together but do the wrong time at run time since
> they wouldn't agree on all the other details that need to be
> determined to implement the C++ object model like layout of classes,
> vtables etc.
Right - that was my guess, but I didn't want to assume. So
in other words, C++ has an explicitly non-standardized
meta object protocol.
Wade Humeniuk
> What does this mean?
Oh, yes, one more thing. I was slightly pissed at Erann for
dumping on Edi like that. I guess there really are savages
in c.l.lisp
Wade
Hartmann Schaffer
rp...@rpw3.org (Rob Warnock) writes:
> Pascal Costanza <cost...@web.de> wrote:
> +---------------
>| The good thing about Common Lisp and its ANSI standard is that it is
>| mainly derived from decades of actual programming experience with Lisp
>| dialects. So this standard is a unique example of things that weren't
>| designed and then forced upon a community without actual experience, but
>| just the other way around: Lisp programmers identified common idioms and
>| agreed upon compromises between mostly superficial differences.
> +---------------
>
> <RANT>
> Actually, this is the way *ALL* standards used to work, up until
> around 1980 or so!!! Until then, the assumption was that you didn't
> try to "standardize" something until there was enough experience to
> know what was good and what was bad, and then you tried to standardize
> the "best current practice" or some reasonable compromise thereof.
>
> But then something happened, I'm not quite sure what. Suddenly the
> default modus operandi became "design by standards committee", with
probably to overcome the drawback of the old standardization process:
since it had to standardize existing implementations, controversial
areas were either left out or the standard was left ambiguous enough
that conflicting implementations could claim to be standard.
many years ago, somebody who was on the fortran66 standards committee
told me that, the night before the final vote, he had to rewrite one
section in order for the standard to be accepted. apparently function
and procedure calls had developed two argument passing mechanisms:
call by reference and call by value/return, both of them used equally
by various implementation, with no side willing to budge. so he had
to rewrite the section so that it was acceptable to both parties,
which didn't do much for program portability
hs
--
Patriotism is the last refuge of the scoundrel
Samuel Johnson
Patriotism is your conviction that this country is superior to all
others because you were born in it
George Bernard Shaw
Frank A. Adrian
> Why is it ok to have a lot of tools in the Unix/Shell/C development
> which have to play together nicely to get you program going. So
> explain why do we have the automake+autoconf tools but why is it not
> ok to have to load asdf?
Because the stuff is already there to use in Unix/Shell/C? Because
loading stuff in most Unix systems is as simple as unzipping a tarball?
Yes, sometimes the make script doesn't work. Sometimes an RPM has a
dependency that you need to track down. And when that happens, I curse
the UNIX system just as much and consider it just as much a pain in the
ass as loading libraries into a Lisp system is. So we're agreed.
automake and autoconfig and everything else sucks. Does that mean our
tool has to suck, too? Is this a new philosophy? Because worse is
better, the suckier you make things and the harder they are to use, the
better it is?
I've never bought the "worse is better" argument. I'll believe that
"worse has more market share because it gets to market more quickly" or
"because worse is out there more quickly it gets worked on more", but
worse is *not* better - it's usually an excuse for laziness and promotion
of mediocrity.
> Why do you think file system interfaces are standard? I know just one
> language which tries to offer a common interface. Others have simply
> followed the Unix conventions and do not even care about a file system
> interface. Now to the different things you think are now standard.
>
> - multiprocessing. Well you can have a look at CL-HTTP or
> PortableAllegroServe and you'll find a common interface there. What's
> you problem using it?
>
> - FFI now there does exist UFFI, which seems to be good enough. What
> prevents you from using it?
>
> - socket interface. Again feel free to use the existing libraries as
> base.
I have no problem using them. It's just a pain in the ass to use them
compared with systems that have them built in. Why do you want to force
everyone who uses these facilities to go through this? Is it some sort of
macho thing? Is there some value in the struggle? Does it build character?
> If you do not want do that yourself. Go to www.franz.com, or
> www.lispworks.com and buy it all in one package...
And then I lose portability. Great. Why use a "portable" language at all
then?
> ...or feel free to sponsor
> the development of "the" portable packages you want to have.
Except I don't want only "portable", I want "standard".
You know, after a while, I feel like saying "Screw it. These guys just
don't get it." And, if I, as a long time Lisp user (and promoter of Lisp),
am beginning to feel this way, think of everyone else out there. Maybe
Paul Graham is right and Common Lisp has become an evolutionary dead end.
I'll still use it because it's the best thing out there, but God knows I'm
not going to promote it to people as having modern functionality because
the *language* doesn't. Instead, I have to tell them, "Yes, you can get
all the modern stuff you want, but there's no standard way of doing it.
You can expect that either your code will be (a) non-portable or (b)
incompatible with someone else's functionality that uses different
portability wrapper libraries. Oh yeah, and user community likes it this
way and will fight hammer and tong to keep it this way."
I will say that this thread *has* done one thing for me - it's gotten me
to understand at least part of Paul Graham's argument for ARC.
faa