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.
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, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Dave Roberts wrote:
> 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
> 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 ······@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
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> 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.
Carl Shapiro <·············@panix.com> writes:
> Fred Gilham <······@snapdragon.csl.sri.com> writes:
>
> > 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.
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 ······@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
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> Carl Shapiro <·············@panix.com> writes:
>
> > Fred Gilham <······@snapdragon.csl.sri.com> writes:
> >
> > > 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.
>
> 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 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 ·····@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
Duane Rettig <·····@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 ······@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
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> > > 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...
--
Duane Rettig ·····@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
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! 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
Wade Humeniuk <········@telus.delete.net> writes:
> 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...
--
Duane Rettig ·····@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
Duane Rettig <·····@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.
--
An amateur practices until he gets it right,
A professional practices until she can't get it wrong.
Lieven Marchand <···@wyrd.be> writes:
> Duane Rettig <·····@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.
--
Duane Rettig ·····@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
Duane Rettig <·····@franz.com> writes:
> Lieven Marchand <···@wyrd.be> writes:
>
> > 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.
Requiring otherwise would be the equivalent of splitting some
definitions of a generic functions (different specialisations and
:before methods etc.) in 2 files, compiling the two with a different
CL compiler and expecting to load the 2 fasls in either implementation
and have it working.
This works on some popular architectures with C compilers because the
operating system has fixed the C ABI.
--
An amateur practices until he gets it right,
A professional practices until she can't get it wrong.
Duane Rettig <·····@franz.com> writes:
> 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.
whow, now I'm really surprised since I wrote several times (last time
half an hour ago in cll) about how I find UFFI -- which to me seems
close to Allegro's FFI -- to be very low-level and therefore not suitable
for standardization.
Pardon me, I didn't look at Allegro's FFI during the last years, so I
don't know whether it improved.
For example, I wrote to the UFFI-users list in December 2002:
-------- UFFI-users, December 2002
[...] since I alyways claimed that UFFI as it currently stands is
incredibly low-level (C level). :in/out parameters etc. would help,
variable-sized buffer support also.
Here's real code for CLISP:
(def-c-call-out execvp (:arguments (file c-string) (argv (c-array-ptr c-string)))
(:return-type int)
(:name "execvp"))
I'd like if somebody could show how to do this with UFFI, LW, ACL, CMUCL etc.
--------
UFFI is improving. For example, I noticed how the interface to
gethostname() benefited from the adoption of uffi:with-foreign-object
(I believe this construct was first in Lispworks).
See http://uffi.b9.com/manual/with-foreign-object.html
The older interface in UFFI was clumsier.
Regards,
Jorg Hohle
Telekom/Service Center Security
Joerg Hoehle <······@users.sourceforge.net> writes:
> Duane Rettig <·····@franz.com> writes:
> > 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.
>
> whow, now I'm really surprised since I wrote several times (last time
> half an hour ago in cll) about how I find UFFI -- which to me seems
> close to Allegro's FFI -- to be very low-level and therefore not suitable
> for standardization.
Well, of course. In fact, that is one of the major reasons why
there has been no FFI standardization - the very problem space is
a low-level, operating-sytem/foreign-compiler-dependent one, and
so the solution space must reach down into that problem space. I
also find that the users of our FFI enjoy the control they have over
the interface, especially since many times the very reason for
interfacing to the library (rather than writing the same functionality
in Lisp) is to have efficient access to previously written and optimized
functionality that would cost time and effort to rewrite.
Note that in your quote above, you left out two important pieces of
context:
1. I had gone into a "self-serving" mode - in reality, the Lisp
community isn't well-served if diverse points of view aren't
represented, and that was how this paragraph was written; you
apparently didn't see the smiley implied in the paragraph.
2. You left out the most important piece of the paragraph:
| 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).
One other reason why FFI hasn't been standardized is that it is
too low-level in the opposite direction as well - the interface to
the lisp itself assumes a particular implementation of the lisp.
> Pardon me, I didn't look at Allegro's FFI during the last years, so I
> don't know whether it improved.
Well, I don't know how long "last years" means; our interface is indeed
constantly improving, but its basic concept has remained the same since
it was rewritten for Allegro CL 5.0 in 1997/1998 timeframe.
> For example, I wrote to the UFFI-users list in December 2002:
> -------- UFFI-users, December 2002
> [...] since I alyways claimed that UFFI as it currently stands is
> incredibly low-level (C level). :in/out parameters etc. would help,
> variable-sized buffer support also.
>
> Here's real code for CLISP:
> (def-c-call-out execvp (:arguments (file c-string) (argv (c-array-ptr c-string)))
> (:return-type int)
> (:name "execvp"))
> I'd like if somebody could show how to do this with UFFI, LW, ACL, CMUCL etc.
Without further specification about the foreign type constructs
(which Allegro CL has, by the way) it can't in general be done in
brand-X CL. Many CL implementations have several other extensions
that force foreign calls to be more explicit than shown above when
making such calls:
1. Multiprocessing: This may be in the form of stack-groups, os-threads,
or even simultaneous multi-processor support. A foreign call must be
able to be specified as preempt-able or not (i.e. can another lisp
process run while the foreign call is currently being executed?)
2. Data movement: Many of the most effective allocation/GC styles
move their data around, but C is not used to seeing this kind of
data movement. Thus, if a GC occurred during a foreign call (perhaps
due to the preemption in #1, which might allocate and thus cause a gc)
and of this GC caused data to move out from under the pointers that
were sent to the foreign function, it would be Bad News. So there
must be a way to specify how to ensure that the data sent is static
(i.e. it won't move) and if explicit static areas are used to
allocate copies of these objects (as opposed to allocating on the
stack) then there must be a protocol for de-allocating them as well.
3. External constraints: Operating systems, or even the standard
calling conventions, may place extra constraints on the FFI which
force it to be more explicit. For example, Windows has several
calling conventions, of which the most major two are Pascal (aka
stdcall) and C. These conventions must be matched, but no other
OS makes such a distinction, so any :convention interface argument
would be Windows-specific, even if it were provided on all versions
of a CL for portability. This kind of specification is low-level.
So your example code is too _high_ level for standardization.
> UFFI is improving. For example, I noticed how the interface to
> gethostname() benefited from the adoption of uffi:with-foreign-object
> (I believe this construct was first in Lispworks).
> See http://uffi.b9.com/manual/with-foreign-object.html
> The older interface in UFFI was clumsier.
Our "new" Allegro CL FFI (the one from 1997/1998) has always had
foreign-types, and several ways to allocate them, and we are still
improving on these interfaces as well. Note that the comment in
the referenced url says that our static allocation performs better
than the versions which stack-allocate the buffer for the object,
but there may be good reasons why one would want to stack-allocate
the buffer anyway, so I consider the lack of ability to specify
the allocation style to be a lack.
In short, you've complained that FFIs are too low-level, and
I agree, and submit that that problem is precisely what makes it
so hard to create a standard for all FFIs for all lisps.
--
Duane Rettig ·····@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
In article <·············@franz.com>, Duane Rettig <·····@franz.com>
wrote:
> Well, of course. In fact, that is one of the major reasons why
> there has been no FFI standardization - the very problem space is
> a low-level, operating-sytem/foreign-compiler-dependent one, and
> so the solution space must reach down into that problem space.
Not necessarily. One could standardize a least-common-denominator with
optional extensions. A good candidate for the LCD FFI would be calls to
ANSI C with no pre-emption and no GC allowed during calls.
> (def-c-call-out execvp (:arguments (file c-string) (argv (c-array-ptr c-string)))
> (:return-type int)
> (:name "execvp"))
> Many CL implementations have several other extensions
> that force foreign calls to be more explicit than shown above when
> making such calls:
>
> 1. Multiprocessing: ...
> 2. Data movement: ...
> 3. External constraints: ...
> So your example code is too _high_ level for standardization.
This is exactly why examples (and implementations) are useful for
illustration or proof-of-concept, but not for standardization. Nothing
in the example implies that there could not be additional arguments to
specify such things with reasonable defaults if they are unspecified.
E.
On Fri, 14 May 2004 08:59:53 -0700, Duane Rettig wrote:
> Well, of course. In fact, that is one of the major reasons why
> there has been no FFI standardization - the very problem space is
> a low-level, operating-sytem/foreign-compiler-dependent one, and
> so the solution space must reach down into that problem space. I
> also find that the users of our FFI enjoy the control they have over
> the interface, especially since many times the very reason for
> interfacing to the library (rather than writing the same functionality
> in Lisp) is to have efficient access to previously written and optimized
> functionality that would cost time and effort to rewrite.
One solution to these sorts of issues is to define a layered API, with the
top level being declarative and abstract for "normal case" use and a lower
level API for the times when users need that degree of control. The
resulting system would be simpler for those who have normal needs while
retaining the power for those whose needs are more complex.
faa
Duane Rettig <·····@franz.com> wrote in message news:<·············@franz.com>...
> - 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
Fred Gilham wrote:
>
>> 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.
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Cameron MacKinnon wrote:
>
> 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
Wade Humeniuk wrote:
> 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."
--
Cameron MacKinnon
Toronto, Canada
"Cameron MacKinnon" <··········@clearspot.net> wrote in message
···························@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
(·····@msoft.com)
In article <··············@uni-berlin.de>,
"Will Hartung" <·····@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.
"Erann Gat" <·········@flownet.com> wrote in message
····································@nntp1.jpl.nasa.gov...
> In article <··············@uni-berlin.de>,
> "Will Hartung" <·····@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
(·····@msoft.com)
In article <··············@uni-berlin.de>,
"Will Hartung" <·····@msoft.com> wrote:
> "Erann Gat" <·········@flownet.com> wrote in message
> ····································@nntp1.jpl.nasa.gov...
> > In article <··············@uni-berlin.de>,
> > "Will Hartung" <·····@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.
Erann Gat <·········@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. 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 ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
On Fri, May 07, 2004 at 04:43:03AM +0000, Peter Seibel wrote:
> 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 <·······@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 wrote:
> On Fri, May 07, 2004 at 04:43:03AM +0000, Peter Seibel wrote:
>> 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.''
Or perhaps it could come preloaded in the CLisp core?
On Fri, 07 May 2004 04:43:03 GMT, Peter Seibel <·····@javamonkey.com> wrote:
> 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.
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
> Erann Gat <·········@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.
Erann Gat <·········@flownet.com> writes:
> In article <··············@javamonkey.com>,
> Peter Seibel <·····@javamonkey.com> wrote:
>
>> Erann Gat <·········@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 ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
> Erann Gat <·········@flownet.com> writes:
>
> > In article <··············@javamonkey.com>,
> > Peter Seibel <·····@javamonkey.com> wrote:
> >
> >> Erann Gat <·········@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.
Erann Gat <·········@flownet.com> writes:
> In article <··············@javamonkey.com>,
> Peter Seibel <·····@javamonkey.com> wrote:
>
>> Erann Gat <·········@flownet.com> writes:
>>
>> > In article <··············@javamonkey.com>,
>> > Peter Seibel <·····@javamonkey.com> wrote:
>> >
>> >> Erann Gat <·········@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.
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
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> 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.
I agree.
One thing that is easy to forget when reading the (sometimes excessively
formal) RFCs are that the name stands for "Request For Comments".
It doesn't need to actually go somewhere; the discussion is valuable in
itself. So how about someone starts writing them, and we see what
happens?
(I'll do it myself, if nothing else shows up. I'd do a bad job, but I'd be
doing *something*, and it couldn't possibly hurt.)
Svein Ove Aas <··············@brage.info> writes:
> Peter Seibel wrote:
>
> > 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.
>
> I agree.
> One thing that is easy to forget when reading the (sometimes excessively
> formal) RFCs are that the name stands for "Request For Comments".
>
> It doesn't need to actually go somewhere; the discussion is valuable in
> itself. So how about someone starts writing them, and we see what
> happens?
>
> (I'll do it myself, if nothing else shows up. I'd do a bad job, but I'd be
> doing *something*, and it couldn't possibly hurt.)
····@rpw3.org (Rob Warnock) writes:
> Edi Weitz <···@agharta.de> wrote:
> +---------------
> | 2. I'm pretty sure that it doesn't make sense to standardize anything
> | until you have a reference implementation which has been in use for
> | some time.
> +---------------
>
> This is *very* important, as I implied in my "rant" this past Friday.
> Standards design by wishful thinking simply doesn't work.
From the above, let me distil highlight two key points:
- the discussion is valuable in itself
- it doesn't make sense until you have a reference implementation.
Is this whole extending (the) Lisp (standard) can of worms an area
where we might learn something from the way the Python folks do
it. I'm thinking of the Python Enhancement Proposal (PEP) mechanism:
http://www.python.org/peps/pep-0001.html
Essentially, when someone cares sufficiently about something being
added to Python, he should write a PEP, which acts as a baseline for
discussion of the subject within the community. Usually a reference
implementation is involved.
Could we not create a "Lisp Layered Standard Proposal" mechanism ?
It could consist of a list of LLSPs[*] similar to the list of PEPs, and a
repository of reference implementations of the proposals.
Perhaps it could be hosted on common-lisp.net
That way, people who care enough about extending the Lisp standard
would have a focussed context for discussing it, and a place where to
contribute work towards fulfilling the dream of such an extended
standard.
I would hope that, after some time, a bunch of people who care will
have thrashed out the details and come to some concensus on some
proposed LLSP. Those on which broad agreement has been reached would
be prime candidates for becoming a de-facto standard. This,
potentially, has some advantages over people writing competing
implementations with different interfaces, and throwing them into the
ring.
Even areas which would require hacking the implementation itself
rather than writing a library (such as threading), could benefit if
some concensus were reached on the interface and other
characteristics. Vendors might care to be able to say that their
implementation conforms to LLSP 103 ... hopefully because they would
have been instrumental in arriving at the final form of the LLSP
itself.
In the ideal situation, a few years of community effort would result
in a whole bunch of LLSPs being bundled together to form the Common
Lisp Community Standard 2008, which all vendors would choose to
support out of the box ... leaving the door open (and the route
well-trodden) to a later Common Lisp Community Standard ...
It seems clear to me that we are not going to have an updated
standards-body-backed Lisp standard within the next decade or two, but
I also get the impression that there are quite a few people out there
who would contribute towards a less formal one, but lack a focal
point. A PEP-like scheme could be just what is needed.
Of course, the PEPs have a dictator who has the power to resolve
disputes ... which is something Lisp does not have. This has both its
advantages and disadvantages.
[*] Or maybe "Lisp Incremental Standard Proposal" ie LISP :-)
Jacek Generowicz wrote:
> Is this whole extending (the) Lisp (standard) can of worms an area
> where we might learn something from the way the Python folks do
> it. I'm thinking of the Python Enhancement Proposal (PEP) mechanism:
>
> http://www.python.org/peps/pep-0001.html
I also think that SRFI is a useful model:
http://srfi.schemers.org/srfi-process.html
I also like the format the the ANSI CL process obviously used - see the
various "issues" in the HyperSpec.
> Of course, the PEPs have a dictator who has the power to resolve
> disputes ... which is something Lisp does not have. This has both its
> advantages and disadvantages.
We don't need no dictatorship. (We don't need no thought control... ;)
I think such a "standardization" scheme has the following benefits:
- It gives people a reference framework to use in descriptions of other
libraries, for example. ("The collection framework according to LLSP
0815". This is not unlike the design patterns, which are essentially
just names for commonly used techniques.) This means that resolution of
disputes is not strictly necessary - if some parties cannot agree, they
can just fork their own LLSP variant, and then see what works best in
practice.
- As Erann said, it gives you some basic guarantees what you can rely
upon in the implementation of an "LLSP".
- It gives the outsiders a semi-official catalogue of things that do
exist, without the need to google through the various diversified resources.
Especially for the latter goal, one needs a kind of semi-official
"blessing". At the moment, the only organization that could provide such
a service would be the ALU, I guess - however, they need more members in
order to get a critical mass of people, AFAICS. see
http://www.alu.org/alu/alu-membership
So one possible way for all those interested in more standards would be
to join the ALU and then work on some semi-official process there.
Of course, there are probably other ways, but these are my random
thoughts on this subject. I just don't think that a pure grassroots
approach would succeed.
I still think it's a bit too early for something like this. It would
give a really bad impression if one started such a process, but then
there wouldn't be enough real proposals. (Maybe a cliki page would be
helpful that collects possible proposals - those for which
implementations already exist, not a wish list - to see how far we would
get...)
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/
Pascal Costanza <········@web.de> writes:
> - It gives the outsiders a semi-official catalogue of things that do
> exist, without the need to google through the various diversified
> resources.
>
> Especially for the latter goal, one needs a kind of semi-official
> "blessing". At the moment, the only organization that could provide
> such a service would be the ALU, I guess - however, they need more
> members in order to get a critical mass of people, AFAICS. see
> http://www.alu.org/alu/alu-membership
>
> So one possible way for all those interested in more standards would
> be to join the ALU and then work on some semi-official process there.
A different model works in the C++ community [1]: To develop the
next-generation standard libraries they do not rely on formal
memberships but merely on good arguments and technical expertise.
The users don't seem to be overly bothered that there's no official
blessing of the libs yet. The important thing is that (1) libs can be
found at a central location (2) there is a _strong_ peer review
process (with lots of discussion!) which ensures quality (3) the stuff
is tested, documented, and portable.
[1] http://www.boost.org/
Matthias <··@spam.pls> writes:
> Pascal Costanza <········@web.de> writes:
> > - It gives the outsiders a semi-official catalogue of things that do
> > exist, without the need to google through the various diversified
> > resources.
> >
> > Especially for the latter goal, one needs a kind of semi-official
> > "blessing". At the moment, the only organization that could provide
> > such a service would be the ALU, I guess - however, they need more
> > members in order to get a critical mass of people, AFAICS. see
> > http://www.alu.org/alu/alu-membership
> >
> > So one possible way for all those interested in more standards would
> > be to join the ALU and then work on some semi-official process there.
>
> A different model works in the C++ community [1]: To develop the
> next-generation standard libraries they do not rely on formal
> memberships but merely on good arguments and technical expertise.
What happens if more than one set of good arguments and technical
expertise exist, and these are diametrically opposed and
irreconcilable? How do they resolve the impasse?
--
Duane Rettig ·····@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
Duane Rettig <·····@franz.com> writes:
> What happens if more than one set of good arguments and technical
> expertise exist, and these are diametrically opposed and
> irreconcilable? How do they resolve the impasse?
They can push two competing proposals up to the Library Working
Group. That is, they let someone with more authority arbitrate.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Duane Rettig <·····@franz.com> writes:
> Matthias <··@spam.pls> writes:
>>
>> A different model works in the C++ community [1]: To develop the
>> next-generation standard libraries they do not rely on formal
>> memberships but merely on good arguments and technical expertise.
>
> What happens if more than one set of good arguments and technical
> expertise exist, and these are diametrically opposed and
> irreconcilable? How do they resolve the impasse?
This is C++ we're talking about, here. They're lucky if they get
*ONE* good argument. I won't comment on technical expertise.
Matthias wrote:
> A different model works in the C++ community [1]: To develop the
> next-generation standard libraries they do not rely on formal
> memberships but merely on good arguments and technical expertise.
...and probably the money to pay people to do the actual work.
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/
Matthias wrote:
> Pascal Costanza <········@web.de> writes:
>
>>- It gives the outsiders a semi-official catalogue of things that do
>>exist, without the need to google through the various diversified
>>resources.
>>
>>Especially for the latter goal, one needs a kind of semi-official
>>"blessing". At the moment, the only organization that could provide
>>such a service would be the ALU, I guess - however, they need more
>>members in order to get a critical mass of people, AFAICS. see
>>http://www.alu.org/alu/alu-membership
>>
>>So one possible way for all those interested in more standards would
>>be to join the ALU and then work on some semi-official process there.
>
>
> A different model works in the C++ community [1]: To develop the
> next-generation standard libraries they do not rely on formal
> memberships but merely on good arguments and technical expertise.
>
> The users don't seem to be overly bothered that there's no official
> blessing of the libs yet. The important thing is that (1) libs can be
> found at a central location (2) there is a _strong_ peer review
> process (with lots of discussion!) which ensures quality (3) the stuff
> is tested, documented, and portable.
>
> [1] http://www.boost.org/
Boost is a good thing. However, that works for "libraries" not for
implementation supported features like FFI. You can write the UFFI, but
that is still going to be a layer on top of an implementation dependent
documented feature.
Cheers
--
Marco
Hello!
Marco Antoniotti <·······@cs.nyu.edu> wrote:
>[...]
>> [1] http://www.boost.org/
>Boost is a good thing. However, that works for "libraries" not for
>implementation supported features like FFI. You can write the UFFI, but
>that is still going to be a layer on top of an implementation dependent
>documented feature.
Parts of Boost *do* access implementation dependent features (like the
BSD style socket API, which is not ISO C/C++) and provide portability/
convenience layers above that.
Kind regards,
Hannah.
Hannah Schroeter wrote:
> Hello!
>
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>>[...]
>
>
>>>[1] http://www.boost.org/
>
>
>>Boost is a good thing. However, that works for "libraries" not for
>>implementation supported features like FFI. You can write the UFFI, but
>>that is still going to be a layer on top of an implementation dependent
>>documented feature.
>
>
> Parts of Boost *do* access implementation dependent features (like the
> BSD style socket API, which is not ISO C/C++) and provide portability/
> convenience layers above that.
That is not the point. The BSD style socket API is "not under the
control" (quotes mandatory) of any C++ compiler implementor. The point
is that Boost (AFAIU, I may be wrong) does not necessarily work
"outside" the C++ standard or other well documented libraries. Without
getting in the intricacies of the FFI, just to get
(parse-namestring ".bashrc")
on a UNIX filesystem to behave consistently across implementations
requires an intervention at the implementation level that is beyond
(again AFAIU) the scope of something like Boost.
Cheers
--
Marco
I had a bit of an uv ejad experience last night. I was wonering about
palindromes and someone pointed me to a page on Norvig's site where he
did a doozy based on "A man, a plan, a canal, Panama!" in Python.
Then I got curious about his posting to cll. Well, I found this
thread which was rather surprising (someone already mentioned the
periodicity of this topic):
http://groups.google.com/groups?hl=en&lr=&threadm=da69ff6a.0205190748.3506f036%40posting.google.com&rnum=2&prev=/groups%3Fsafe%3Dimages%26as_ugroup%3Dcomp.lang.lisp%26as_uauthors%3Dpeter%2520norvig%26as_scoring%3Dd%26lr%3D%26num%3D100%26hl%3Den
I think there is less mystery about old posters not posting here
anymore. We need to debate something new!
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Boost is a good thing. However, that works for "libraries" not for
> implementation supported features like FFI. You can write the UFFI,
> but that is still going to be a layer on top of an implementation
> dependent documented feature.
If there's a working, documented, truly portable UFFI I, as
application developer or library writer/porter, don't care about the
underlying FFI more than I care about the binary layout my C++
compiler generates. That is: very little. It's one level below my
abstraction threshold.
But it might be possible, I'm not expert enough to judge that, that a
truly portable, fully-functional UFFI is an illusion unless the FFIs
are somehow standardized. (I.e., that different ways to do GC of
FFI-objects or callbacks to/from CL cannot efficiently be abstracted
away from the user). Is this what you mean?
Erann Gat <·········@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.
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.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <··············@plato.moon.paoloamoroso.it>,
Paolo Amoroso <·······@mclink.it> wrote:
> Erann Gat <·········@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.
Erann Gat <·········@flownet.com> writes:
> In article <··············@plato.moon.paoloamoroso.it>,
> Paolo Amoroso <·······@mclink.it> wrote:
>
> > Erann Gat <·········@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erann Gat <·········@flownet.com> writes:
> In article <··············@plato.moon.paoloamoroso.it>,
> Paolo Amoroso <·······@mclink.it> wrote:
>
>> Erann Gat <·········@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 ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Paolo Amoroso <·······@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.
Mario S. Mommer <········@yahoo.com> writes:
> > No apologies, no excuses, no serious thought: just do it.
>
> What is this? Voices of reason in c.l.l? :-)
No, he's just wearing Nikes.
Meanwhile, Darwin has been in charge of standards (defacto and
otherwise) the entire time. Many people just have misconceptions
about how natural selection works.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
On Mon, 10 May 2004 01:56:04 +0000, David Steuber wrote:
> Meanwhile, Darwin has been in charge of standards (defacto and
> otherwise) the entire time. Many people just have misconceptions
> about how natural selection works.
Darwin's all fine and good, but for lower life forms (and for man-made
artifacts,in particular), I've always thought eugenics works a bit faster
(but that just might be my farm upbringing talking :-).
faa
David Steuber wrote:
> Mario S. Mommer <········@yahoo.com> writes:
>
>
>>>No apologies, no excuses, no serious thought: just do it.
>>
>>What is this? Voices of reason in c.l.l? :-)
>
>
> No, he's just wearing Nikes.
I had that tokenized: "Nike, Crunch gyms, Bush: Nike"
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Sat, 08 May 2004 13:42:48 +0200, Paolo Amoroso <·······@mclink.it> wrote:
> Here is the process:
>
> CL-PPCRE is the recommended standard for regular expressions in
> Common Lisp.
Guys, I'm honored that you think so high of CL-PPCRE but as its author
let me argue that I do /not/ think this is a good idea.
CL-PPCRE is the result of a bet. I wanted to show that it's possible
to write an implementation of Perl's regex engine which is comparable
in speed to the original one (which is written in C). It turned out
that I not only won the bet but the result was quite useful, so I made
sure it ran on the Lisps I had access to and I published and
maintained it, i.e. I fixed bugs when they were reported and added
features if I thought they would fit. I'm willing to continue to do
this if time permits. But that's not the point.
The point is that due to its origin CL-PPCRE has two very serious
drawbacks:
1. It is optimized for speed. And it's optimized for CMUCL.
As a consequence, the code is partly very ugly and has a lot of
"dark corners" that are only there because I wanted to squeeze
another microsecond out of it. Also, while I initially tweaked it a
lot for CMUCL I didn't do much for other Lisps. For example, I
recently had an interesting discussion with Duane Rettig who
provided me with some very good ideas on how to improve CL-PPCRE's
performance on AllegroCL. (These will appear in one of the next
releases, I need some time to integrate them cleanly with the
rest.)
Anyway, you might not notice this if you're just using CL-PPCRE but
if you look at the source you probably don't want it to be a
"reference implementation" or something like this.
2. Probably more important: CL-PPCRE tries to be as close to Perl as
possible. I originally thought this was a good idea because Perl's
regular expression flavor is not only used in Perl but also in
Python, Java, XML Schema, PHP, and Apache. However, CL-PPCRE is
closer to Perl than you might wish for a CL standard.
While I was working on CL-PPCRE I became convinced that Perl's
regular expressions are ill-defined and even the stuff that's
properly defined is partly based on brain-dead (IMHO)
decisions. For me it was easy "to do the right thing" in CL-PPCRE
if in doubt: Just fire up Perl and look what it does. But that's
not what I would want for a CL standard...
What's the bottom line? I think that the core of CL-PPCRE /might/ be
useful as a starting point to work towards a reference implementation
for CL regular expression. CL-PPCRE in its current form isn't.
As for the general discussion we're having here:
1. Yes, I think it would be tremendously useful if we had standards or
"sub-standards" for things like system definition, foreign
functions, multi-threading, OS access, etc.
2. I'm pretty sure that it doesn't make sense to standardize anything
until you have a reference implementation which has been in use for
some time.
3. I don't think this'll go anywhere unless the major commercial
vendors take part.
4. And I doubt that this will happen any time soon.
Oh, and one more thing: I didn't include regular expressions in the
list above because CL-PPCRE and some other regex libraries out there
(look, e.g., at Michael Parker's "clawk" which predates CL-PPCRE) show
that you can write acceptable code in a completely portable way. I
wonder if it makes sense to standardize something like this. I'd be
/much/ more interested in talking about what you can't do with ANSI CL
alone.
Just my .02 EUR.
Cheers,
Edi.
Edi Weitz <···@agharta.de> wrote:
+---------------
| 2. I'm pretty sure that it doesn't make sense to standardize anything
| until you have a reference implementation which has been in use for
| some time.
+---------------
This is *very* important, as I implied in my "rant" this past Friday.
Standards design by wishful thinking simply doesn't work.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Peter Seibel <·····@javamonkey.com> wrote:
+---------------
| Edi Weitz <···@agharta.de> writes:
| > Oh, and one more thing: I didn't include regular expressions in the
| > list above because CL-PPCRE and some other regex libraries out there
| > (look, e.g., at Michael Parker's "clawk" which predates CL-PPCRE)
| > show that you can write acceptable code in a completely portable
| > way. I wonder if it makes sense to standardize something like this.
| > I'd be /much/ more interested in talking about what you can't do
| > with ANSI CL alone.
|
| We may still be using "standardize" in different ways. To me CL-PPCRE
| is the "standard" regexp library exactly when it is the clear answer
| to the question "How do I do regexps in Common Lisp?" I recognize that
| this is quite different than a written standard that has been produced
| by a particular formal process and which was designed to be multiply
| implemented. Exactly because it doesn't need anything more than what's
| already provided by Common Lisp, there don't *have* to be multiple
| implementations. Just one that we agree to use. I have been trying to
| use "de facto standard" to make this keep this distinction clear but
| maybe that wasn't enough.
+---------------
It may be that "standard" has become too associated with heavy-weight
process". What if we just called such things the "community concensus
on best current practice(s)"? We could have a "Best%20Current%20Practice"
CLiki page, and what's on it could change with over time with experience.
It could also list topics for which there was no clear single concensus,
but for which there were several respected contenders.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Peter Seibel <·····@javamonkey.com> wrote:
--snipping lots of good points--
> We may still be using "standardize" in different ways. To me CL-PPCRE
> is the "standard" regexp library exactly when it is the clear answer
> to the question "How do I do regexps in Common Lisp?"
We obviously need more and better terminology. ;)
The way I understand these terms (and I suspect I'm not alone) goes like
this:
Standard
We currently have only one, the ANSI one.
De facto standard
Interface implemented by several vendors, possibly with
some differences. Has a specification independed of vendor
documentation. Examples: MOP, Gray streams, CLIM.
I think these two distinctions are worthwhile to keep separate from the
notion of good, portable, and commonly used libraries.
How about
Semi-standard library
for those? Granted, this is not an important distiction when telling a
newbie to use CL-PPCRE or ASDF, but when talking about eg. "Modernizing
Common Lisp" it makes sense to have that distinction...
My flamethrower is out of gas, which is no fun as long as the "no, that's
not a standard, this is!" keeps on. Do I have to get some more, or can we
agree on not calling libraries standards when they're not? ;-)
Cheers,
-- Nikodemus
·········@random-state.net writes:
> Peter Seibel <·····@javamonkey.com> wrote:
>
> --snipping lots of good points--
>
>> We may still be using "standardize" in different ways. To me CL-PPCRE
>> is the "standard" regexp library exactly when it is the clear answer
>> to the question "How do I do regexps in Common Lisp?"
>
> We obviously need more and better terminology. ;)
>
> The way I understand these terms (and I suspect I'm not alone) goes like
> this:
>
> Standard
>
> We currently have only one, the ANSI one.
>
> De facto standard
>
> Interface implemented by several vendors, possibly with
> some differences. Has a specification independed of vendor
> documentation. Examples: MOP, Gray streams, CLIM.
>
> I think these two distinctions are worthwhile to keep separate from
> the notion of good, portable, and commonly used libraries.
>
> How about
>
> Semi-standard library
>
> for those? Granted, this is not an important distiction when telling
> a newbie to use CL-PPCRE or ASDF, but when talking about eg.
> "Modernizing Common Lisp" it makes sense to have that distinction...
I'll be happy to try and reserve the terms "standard" and "de facto
standard" for the meanings you give above if we can somehow find a way
to answer the questions, "Is there a standard way to do regexps in
Common Lisp?" or, "Is there a standard regexp library?" with something
other than a lecture about how *no* language has a *standard* for
regexps (unless they happen to literally implement the POSIX standard
I suppose).
Exactly the kind of people who are going to ask questions like
this--newbies--are the ones who may not yet be attuned to the subtle
nuances of the word "standard", particularly if they are coming from a
language where the whole thing is a "standard by implementation". In
other words, recognize that both of the following (from Merriam
Webster online, s.v.) are legitimate definitons of the word "standard"
and they may be using the second rather than the first:
1a. constituting or conforming to a standard especially as
established by law or custom <standard weight>
2a. regularly and widely used, available, or supplied <standard
automobile equipment>
> My flamethrower is out of gas, which is no fun as long as the "no, that's
> not a standard, this is!" keeps on. Do I have to get some more, or can we
> agree on not calling libraries standards when they're not? ;-)
Well, I'll certainly try to avoid refering to a library as "a
standard" (i.e. the noun form) since that doesn't make much sense. And
if it'll keep the peace I'll try to avoid using the adjectival form 2a
when it could confused with 1a. But following the, be liberal in what
you accept; strict in what you emit philosophy, I'm not going to jump
all over someone who innocently asks "is there a standard way to do X"
when they mean is there a regularly and widely used, available, or
supplied way of doing X. Is that cool?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> I'll be happy to try and reserve the terms "standard" and "de facto
> standard" for the meanings you give above if we can somehow find a way
> to answer the questions, "Is there a standard way to do regexps in
> Common Lisp?" or, "Is there a standard regexp library?" with something
> other than a lecture about how *no* language has a *standard* for
> regexps (unless they happen to literally implement the POSIX standard
> I suppose).
The standard way to do REs is ... the canonical RE library is ... you
should asdf-install ...
... any good?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
>> I'll be happy to try and reserve the terms "standard" and "de facto
>> standard" for the meanings you give above if we can somehow find a way
>> to answer the questions, "Is there a standard way to do regexps in
>> Common Lisp?" or, "Is there a standard regexp library?" with something
>> other than a lecture about how *no* language has a *standard* for
>> regexps (unless they happen to literally implement the POSIX standard
>> I suppose).
>
> The standard way to do REs is ... the canonical RE library is ... you
> should asdf-install ...
>
> ... any good?
Yup, all good by me. And for bonus points, no reaming the newbies (or
even oldbies) who happen to use "standard" in the colloquial
adjectival sense from time to time.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Yup, all good by me. And for bonus points, no reaming the newbies (or
> even oldbies) who happen to use "standard" in the colloquial
> adjectival sense from time to time.
Hmm, is this still usenet? Doesn't sound that likely, but you never know...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Edi Weitz <···@agharta.de> writes:
> Guys, I'm honored that you think so high of CL-PPCRE but as its author
> let me argue that I do /not/ think this is a good idea.
Which currently available regular expression library would you
recommend?
> CL-PPCRE is the result of a bet. I wanted to show that it's possible
> to write an implementation of Perl's regex engine which is comparable
> in speed to the original one (which is written in C). It turned out
[...]
> The point is that due to its origin CL-PPCRE has two very serious
> drawbacks:
>
> 1. It is optimized for speed. And it's optimized for CMUCL.
If CL-PPCRE under CMUCL is comparable in speed to the C
implementation, its performance is probably good enough with other
Lisps.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
>>>>> "Paolo" == Paolo Amoroso <·······@mclink.it> writes:
Paolo> If CL-PPCRE under CMUCL is comparable in speed to the C
Paolo> implementation, its performance is probably good enough with other
Paolo> Lisps.
I believe this is also true for Clisp, which, we know, is
byte-compiled.
Ray
On Mon, 10 May 2004 13:20:45 -0400, Raymond Toy <···@rtp.ericsson.se> wrote:
>>>>>> "Paolo" == Paolo Amoroso <·······@mclink.it> writes:
>
> Paolo> If CL-PPCRE under CMUCL is comparable in speed to the C
> Paolo> implementation, its performance is probably good enough
> Paolo> with other Lisps.
>
> I believe this is also true for Clisp, which, we know, is
> byte-compiled.
Last time I checked CL-PPCRE on CLISP was comparable to CLISP's own
regex module (which I think is implemented in C). It was /not/
comparable with Perl's regex engine which is indeed pretty fast.
Edi
>>>>> "Edi" == Edi Weitz <···@agharta.de> writes:
Edi> On Mon, 10 May 2004 13:20:45 -0400, Raymond Toy <···@rtp.ericsson.se> wrote:
>> I believe this is also true for Clisp, which, we know, is
>> byte-compiled.
Edi> Last time I checked CL-PPCRE on CLISP was comparable to CLISP's own
Edi> regex module (which I think is implemented in C). It was /not/
Edi> comparable with Perl's regex engine which is indeed pretty fast.
Oops. My apologies for not getting this right. But that's still
pretty impressive that your Lisp version is as fast as Clisp's regex
module, which used to be (still is?) based on GNU regex.
Ray
On Mon, 10 May 2004 17:04:52 +0200, Paolo Amoroso <·······@mclink.it> wrote:
> Edi Weitz <···@agharta.de> writes:
>
>> Guys, I'm honored that you think so high of CL-PPCRE but as its
>> author let me argue that I do /not/ think this is a good idea.
>
> Which currently available regular expression library would you
> recommend?
Short answer: None.
Long answer: I agree with Peter that it's fine to recommend CL-PPCRE
to "newbies" who ask for available regex libraries. I was just trying
to clarify that for me the current API of CL-PPCRE isn't good enough
to be cast in stone and used as a "standard."
Cheers,
Edi.
"Edi Weitz" <···@agharta.de> wrote in message
···················@bird.agharta.de...
> On Mon, 10 May 2004 17:04:52 +0200, Paolo Amoroso <·······@mclink.it>
wrote:
> Long answer: I agree with Peter that it's fine to recommend CL-PPCRE
> to "newbies" who ask for available regex libraries. I was just trying
> to clarify that for me the current API of CL-PPCRE isn't good enough
> to be cast in stone and used as a "standard."
Hmm..."oops"
That's the problem with distributed code.
See, if your library becomes "de facto best practice" (there's a phrase for
ya), then the more its used, the more stoney its API becomes.
Then you get to open up ye olde "compatability" can-o-worms.
The problem is that it can take on a life of its own beyond what you may
wish.
Regards,
Will Hartung
(·····@msoft.com)
Edi Weitz wrote:
> On Sat, 08 May 2004 13:42:48 +0200, Paolo Amoroso <·······@mclink.it> wrote:
>
>
>>Here is the process:
>>
>> CL-PPCRE is the recommended standard for regular expressions in
>> Common Lisp.
>
>
> Guys, I'm honored that you think so high of CL-PPCRE but as its author ...
... lots of wise things.
> Just my .02 EUR.
>
I am willing to give you 20.0 EUR for the wise things you just said :)
Cheers
--
Marco
On Tue, 11 May 2004 10:41:27 -0400, Marco Antoniotti <·······@cs.nyu.edu> wrote:
> Edi Weitz wrote:
>
> ... lots of wise things.
>
>> Just my .02 EUR.
>
> I am willing to give you 20.0 EUR for the wise things you just said
> :)
Cool! I'll send you my account number by private email... :)
Edi.
Edi Weitz wrote:
> On Tue, 11 May 2004 10:41:27 -0400, Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>
>>Edi Weitz wrote:
>>
>> ... lots of wise things.
>>
>>
>>>Just my .02 EUR.
>>
>>I am willing to give you 20.0 EUR for the wise things you just said
>>:)
>
>
> Cool! I'll send you my account number by private email... :)
>
I intended to pay in in pizza and beer :)
Cheers
--
Marco
Edi Weitz <···@agharta.de> writes:
> On Sat, 08 May 2004 13:42:48 +0200, Paolo Amoroso <·······@mclink.it> wrote:
>
> > Here is the process:
> >
> > CL-PPCRE is the recommended standard for regular expressions in
> > Common Lisp.
>
> Guys, I'm honored that you think so high of CL-PPCRE but as its author
> let me argue that I do /not/ think this is a good idea.
>
> CL-PPCRE is the result of a bet. [...]
Wow. I bet you can't write a Lisp replacement of Don Libe's Expect or
code that takes Tcl and writes functionally comparable Lisp code or
any number of other things of which I can not think at the moment
<smile>. Quick, everybody, start betting Edi that he can't do things
in Lisp.
On 01 Oct 2004 13:01:21 -0500, Damien Kick <······@email.mot.com> wrote:
> Wow. I bet you can't write a Lisp replacement of Don Libe's Expect
> or code that takes Tcl and writes functionally comparable Lisp code
> or any number of other things of which I can not think at the moment
> <smile>. Quick, everybody, start betting Edi that he can't do
> things in Lisp.
:)
Well, I wrote CL-PPCRE when I had a little more time than now... :)
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Peter Seibel <·····@javamonkey.com> writes:
> 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 <·······@mclink.it> writes:
> Peter Seibel <·····@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
What is the recommendation for networking/sockets? KMRCL is very good, isn't
it?
"Paolo Amoroso" <·······@mclink.it> wrote in message
...> I have changed my signature for comp.lang.lisp
...
.> Recommended Common Lisp standards (Google for info on each):
> - ASDF/ASDF-INSTALL: system building/installation
> - CL-PPCRE: regular expressions
> - UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
>> Peter Seibel <·····@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 <·····@javamonkey.com>
Recommended Common Lisp standards (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso wrote:
> Incidentally, Lisp
> book authors and bloggers can do a lot for promoting informal, grass
> roots, let's-start-somewhere standards ;-)
Done. See http://www.findinglisp.com/libraries/support_libraries.html
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Peter Seibel wrote:
> 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.
Being a fan of action over thinking, and acting on a suggestion somewhere
crossthread, I went ahead and created
http://www.cliki.net/Current%20recommended%20libraries .
It isn't linked to from very many places, and it lacks useful content as
well, but it's a start. I call it a place to put "good enough" links;
don't misconstrue it as an attempt to set standards.
You're welcome to put more than package per field as well, as long as the
one you consider "most useful" is clearly marked as such. This being
Wiki, which one that is may fluctuate, but hopefully in a Darwinian
fashion.
So... go nuts.
On Fri, 07 May 2004 11:02:12 -0700, Erann Gat <·········@flownet.com> wrote:
> In article <··············@javamonkey.com>,
> Peter Seibel <·····@javamonkey.com> wrote:
>
>> Erann Gat <·········@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.
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de>
wrote:
> On Fri, 07 May 2004 11:02:12 -0700, Erann Gat <·········@flownet.com> wrote:
>
> > In article <··············@javamonkey.com>,
> > Peter Seibel <·····@javamonkey.com> wrote:
> >
> >> Erann Gat <·········@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 <·········@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...
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
In article <··············@midnight.cs.hut.fi>,
·········@random-state.net wrote:
> Erann Gat <·········@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:
>
> 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
In article <·····················@edtnps89>,
Wade Humeniuk <········@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.
From: Friedrich Dominicus
Subject: Re: Modernizing Common Lisp
Date:
Message-ID: <87y8o3comn.fsf@fbigm.here>
Wade Humeniuk <········@telus.delete.net> writes:
> 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?
Friedrich
--
Please remove just-for-news- to reply via e-mail.
In article <····················@clgrps13>,
Wade Humeniuk <········@telus.delete.net> wrote:
[An excerpt from my copyrighted code]
Er, Wade, that code you just published on Usenet was copyrighted. It
was, according to the license terms stated in the Readme file (did you
bother to read the Readme file?), licensed for private use only.
Redistribution was expressly prohibited.
I have for the moment removed the code from the Web, since apparently
Lispers cannot be trusted to respect intellectual property rights.
E.
Erann Gat <·········@flownet.com> writes:
> Er, Wade, that code you just published on Usenet was copyrighted.
> It was, according to the license terms stated in the Readme file
> (did you bother to read the Readme file?), licensed for private use
> only. Redistribution was expressly prohibited.
Welcome to the wonderful world of fair use. Since you've taken the
full work offline, I can't check whether that was the whole of it,
but I rather doubt it. So I'd say the excerpts Wade posted clearly
satisfy the four factors of fair use.
> I have for the moment removed the code from the Web, since apparently
> Lispers cannot be trusted to respect intellectual property rights.
Or can't understand them, I suppose.
--
Alan Shutko <···@acm.org> - I am the rocks.
Erann Gat wrote:
> Er, Wade, that code you just published on Usenet was copyrighted. It
> was, according to the license terms stated in the Readme file (did you
> bother to read the Readme file?), licensed for private use only.
> Redistribution was expressly prohibited.
>
> I have for the moment removed the code from the Web, since apparently
> Lispers cannot be trusted to respect intellectual property rights.
Sorry Erann
Wade
In article <·····················@clgrps13>,
Wade Humeniuk <········@telus.delete.net> wrote:
> Erann Gat wrote:
>
>
> > Er, Wade, that code you just published on Usenet was copyrighted. It
> > was, according to the license terms stated in the Readme file (did you
> > bother to read the Readme file?), licensed for private use only.
> > Redistribution was expressly prohibited.
> >
> > I have for the moment removed the code from the Web, since apparently
> > Lispers cannot be trusted to respect intellectual property rights.
>
> Sorry Erann
You and I seem to have a substantial difference of opinion about how
serious this matter is if you think "Sorry Erann" is an adequate
response.
E.
Erann Gat wrote:
>
> Er, Wade, that code you just published on Usenet was copyrighted. It
> was, according to the license terms stated in the Readme file (did you
> bother to read the Readme file?), licensed for private use only.
> Redistribution was expressly prohibited.
>
> I have for the moment removed the code from the Web, since apparently
> Lispers cannot be trusted to respect intellectual property rights.
>
Again as a more formal apology, I must say I deeply sorry
for my lack of respect for your property. I must say I
did not read the license terms but ignorance is no excuse.
I have cancelled my Usenet post in hopes that no further
damage will be done.
Sincerely, Wade Humeniuk
In article <··················@clgrps13>,
Wade Humeniuk <········@telus.delete.net> wrote:
> Erann Gat wrote:
>
> >
> > Er, Wade, that code you just published on Usenet was copyrighted. It
> > was, according to the license terms stated in the Readme file (did you
> > bother to read the Readme file?), licensed for private use only.
> > Redistribution was expressly prohibited.
> >
> > I have for the moment removed the code from the Web, since apparently
> > Lispers cannot be trusted to respect intellectual property rights.
> >
>
> Again as a more formal apology, I must say I deeply sorry
> for my lack of respect for your property. I must say I
> did not read the license terms but ignorance is no excuse.
> I have cancelled my Usenet post in hopes that no further
> damage will be done.
>
> Sincerely, Wade Humeniuk
OK.
The fact that you posted the code for the purpose of ripping it to
shreds really steamed my clams, particularly when I expressed reluctance
to publish the code in the first place (and put the restrictive license
on) precisely because I knew that it would not be well received in some
quarters and I was not in the mood to be pilloried in public for it.
But, as Alan Shutko points out, what you did was probably fair use in
the legal sense.
But I accept your apology. Let's put it behind us.
E.
* Erann Gat <·········@flownet.com>:
> I have for the moment removed the code from the Web, since apparently
> Lispers cannot be trusted to respect intellectual property rights.
One person does something that violates your licence and you blame every
Lisp programmer. Why? What did I do wrong?
--
Dave Pearson
http://www.davep.org/lisp/
In article <·························@hagbard.davep.org>,
Dave Pearson <··········@davep.org> wrote:
> * Erann Gat <·········@flownet.com>:
>
> > I have for the moment removed the code from the Web, since apparently
> > Lispers cannot be trusted to respect intellectual property rights.
>
> One person does something that violates your licence and you blame every
> Lisp programmer.
Not so. "Blame" implies culpability and responsibility. I didn't
ascribe responsibility to anyone but the perpetrator.
> What did I do wrong?
Well, for starters, you're trying to blame (and I use that word
advisedly) me for something I didn't do.
E.
Erann Gat <·········@flownet.com> writes:
> In article <·························@hagbard.davep.org>,
> Dave Pearson <··········@davep.org> wrote:
>
> > * Erann Gat <·········@flownet.com>:
> >
> > > I have for the moment removed the code from the Web, since apparently
===========================================================^^^^^^^^^^^^^^^^
> > > Lispers cannot be trusted to respect intellectual property rights.
======^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > One person does something that violates your licence and you blame every
> > Lisp programmer.
>
> Not so. "Blame" implies culpability and responsibility. I didn't
> ascribe responsibility to anyone but the perpetrator.
That's not the way I read your generalization. I didn't read it as
an indictment of _every_ Lisper, but I did read it as a
applying to more than just the perpretrator, and thus, in a sense,
a spreading around of blame.
--
Duane Rettig ·····@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
In article <·············@franz.com>, Duane Rettig <·····@franz.com>
wrote:
> Erann Gat <·········@flownet.com> writes:
>
> > In article <·························@hagbard.davep.org>,
> > Dave Pearson <··········@davep.org> wrote:
> >
> > > * Erann Gat <·········@flownet.com>:
> > >
> > > > I have for the moment removed the code from the Web, since apparently
> ===========================================================^^^^^^^^^^^^^^^^
> > > > Lispers cannot be trusted to respect intellectual property rights.
> ======^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >
> > > One person does something that violates your licence and you blame every
> > > Lisp programmer.
> >
> > Not so. "Blame" implies culpability and responsibility. I didn't
> > ascribe responsibility to anyone but the perpetrator.
>
> That's not the way I read your generalization. I didn't read it as
> an indictment of _every_ Lisper, but I did read it as a
> applying to more than just the perpretrator, and thus, in a sense,
> a spreading around of blame.
I live in a community with a homeowner's association. Recently the HOA
board, in an effort to curb speeding on neighborhood streets, started
putting up speed bumps. Only a small minority of the residents actually
speed, and the board knows it. (In fact, this is manifestly true,
because if everyone wanted to speed they'd elect a board that would
permit speeding.) But putting up speed bumps is (the board believes)
the only effective means available to curb speeding.
So the board doesn't "blame everyone" in the sense of believing that
everyone is culpable. Nonetheless, they put up speed bumps (for
everyone) because they believe (with some justification) that (some)
members of the community cannot be trusted to obey the posted speed
limits. It is a most unfortunate and annoying situation.
This situation seems analogous to me. I believe that the vast majority
of the Lisp community is honorable and trustworthy, but that there is a
small minority who are not, and it only takes one of these people to
make publishing my code more trouble than it's worth (for me -- YMMV).
So I'm putting up speed bumps (actually, I'm closing the road until I
have time to build the speed bumps). If anyone has a better idea, I'm
listening. (So is my HOA board.)
E.
P.S. Just to be clear, the issue for me personally is not so much
copyright per se as it is publishing a highly negative critique.
Copyright was just the mechanism I tried to use to prevent this from
happening, and I focused on it because I thought that it would be
relatively uncontroversial. But if someone had posted my code with the
comment "This is really cool" we would probably not be having this
conversation.
I took this precaution because I have seen this sort of thing happen
before. By "this sort of thing" I do not mean copyright violation
(though to be sure I have seen that too) but rather the vicious
pillorying of someone's published code simply because the critiquer
didn't approve of the style or the goal of the code. Recurring
criticism of John Foderaro's if* macro (or CLisp's Menorah banner) comes
to mind. A lot of my code is very much analogous to if*, and so it was
predictable that some people wouldn't approve.
I think it is incumbent upon people who use freely donated code to
understand and honor the desires of the person who donated it. My
desire is that if you don't like my code you either tell me about it in
private or keep it to yourself. I don't think this is unreasonable. In
fact, I think it's just basic common courtesy. But, as I've said
before, that's just my opinion, and my opinion doesn't count any more
than anyone else's -- except under one special circumstance. And this
is it.
Erann Gat <·········@flownet.com> writes:
> In article <·············@franz.com>, Duane Rettig <·····@franz.com>
> wrote:
>
> > Erann Gat <·········@flownet.com> writes:
> >
> > > In article <·························@hagbard.davep.org>,
> > > Dave Pearson <··········@davep.org> wrote:
> > >
> > > > * Erann Gat <·········@flownet.com>:
> > > >
> > > > > I have for the moment removed the code from the Web, since apparently
> > ===========================================================^^^^^^^^^^^^^^^^
> > > > > Lispers cannot be trusted to respect intellectual property rights.
> > ======^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > >
> > > > One person does something that violates your licence and you blame every
> > > > Lisp programmer.
> > >
> > > Not so. "Blame" implies culpability and responsibility. I didn't
> > > ascribe responsibility to anyone but the perpetrator.
> >
> > That's not the way I read your generalization. I didn't read it as
> > an indictment of _every_ Lisper, but I did read it as a
> > applying to more than just the perpretrator, and thus, in a sense,
> > a spreading around of blame.
>
> I live in a community with a homeowner's association. Recently the HOA
> board, in an effort to curb speeding on neighborhood streets, started
> putting up speed bumps. Only a small minority of the residents actually
> speed, and the board knows it. (In fact, this is manifestly true,
> because if everyone wanted to speed they'd elect a board that would
> permit speeding.) But putting up speed bumps is (the board believes)
> the only effective means available to curb speeding.
>
> So the board doesn't "blame everyone" in the sense of believing that
> everyone is culpable. Nonetheless, they put up speed bumps (for
> everyone) because they believe (with some justification) that (some)
> members of the community cannot be trusted to obey the posted speed
> limits. It is a most unfortunate and annoying situation.
>
> This situation seems analogous to me.
Yes, it is a very good analogy.
> I believe that the vast majority
> of the Lisp community is honorable and trustworthy, but that there is a
> small minority who are not, and it only takes one of these people to
> make publishing my code more trouble than it's worth (for me -- YMMV).
> So I'm putting up speed bumps (actually, I'm closing the road until I
> have time to build the speed bumps). If anyone has a better idea, I'm
> listening. (So is my HOA board.)
In a nutshell, translated from your original statement into your
analogy, you said:
"I have for the moment closed the road in order to put up speed bumps,
since apparently members of the community cannot be trusted to obey
the posted speed limits."
Note that this differs slightly from the way you posted your analogy,
where instead of "members of the community..." you added the qualifier
"(some) members of the community ...". It seems like such a minor
thing, but it is always important to make explicit your presumed
qualifiers, because if you don't, the readers will, and some will
insert the qualifier "(all)" or even "(most)" instead of your
intended "(some)".
As for the HOA, some put up gates and regulate access to the
community, and others call the police and ask them to enforce
the speed laws.
> E.
>
> P.S. Just to be clear, the issue for me personally is not so much
> copyright per se as it is publishing a highly negative critique.
> Copyright was just the mechanism I tried to use to prevent this from
> happening, and I focused on it because I thought that it would be
> relatively uncontroversial. But if someone had posted my code with the
> comment "This is really cool" we would probably not be having this
> conversation.
I think that everyone wants this. Unfortunately, programmers tend to
be critics, and thus the tendency is to forego the "good job" and get
down to the "but you missed this feature ...".
> I took this precaution because I have seen this sort of thing happen
> before. By "this sort of thing" I do not mean copyright violation
> (though to be sure I have seen that too) but rather the vicious
> pillorying of someone's published code simply because the critiquer
> didn't approve of the style or the goal of the code. Recurring
> criticism of John Foderaro's if* macro (or CLisp's Menorah banner) comes
> to mind. A lot of my code is very much analogous to if*, and so it was
> predictable that some people wouldn't approve.
I can completely understand this.
> I think it is incumbent upon people who use freely donated code to
> understand and honor the desires of the person who donated it. My
> desire is that if you don't like my code you either tell me about it in
> private or keep it to yourself. I don't think this is unreasonable. In
> fact, I think it's just basic common courtesy. But, as I've said
> before, that's just my opinion, and my opinion doesn't count any more
> than anyone else's -- except under one special circumstance. And this
> is it.
It is also incumbent upon those who donate code freely to understand
that there will always be people who don't honor the desires of the
person who donated it. The reasons will be many, from mistakes made
to outright malfeasance, but it is a fact, and if the donator doesn't
want to contend with such issues, then the donation should be restricted
to those whom the donator trusts. That doesn't fix the problem, but it
at least tends to limit the problem to one that can be easily explained
as a simple mistake.
--
Duane Rettig ·····@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
Erann Gat <·········@flownet.com> writes:
> P.S. Just to be clear, the issue for me personally is not so much
> copyright per se as it is publishing a highly negative critique.
> Copyright was just the mechanism I tried to use to prevent this from
> happening, and I focused on it because I thought that it would be
> relatively uncontroversial.
Actually, US Copyright is intentionally structured to allow
critique. That's because American discourse has a tradition of
open critique being a good thing. Art, literature, science, politics
all have a flourishing community based on public critique.
For instance, I didn't agree with the original critique of your
define-class. I'm not sure I'd use it, but I did see some things I
like. If the debate had gone on, it could have brought up different
points of view and taught us all something, because you made choices
writing your code for reasons which someone else might not see
immediately.
Someone emailing you privately could produce a dialog benefiting you
and the poster, but nobody else would learn from it, nor could their
experiences help you.
It's certainly your prerogative not to post code you don't feel is
worth the effort defending. (I've got a ton of stuff at home like
that.) But I wanted to try to explain why people may have felt
differently about critique; to me, it's not a matter of personal
courtesy, because it's about the code, not the person.
--
Alan Shutko <···@acm.org> - I am the rocks.
In article <··············@wesley.springies.com>,
Alan Shutko <···@acm.org> wrote:
> Erann Gat <·········@flownet.com> writes:
>
> > P.S. Just to be clear, the issue for me personally is not so much
> > copyright per se as it is publishing a highly negative critique.
> > Copyright was just the mechanism I tried to use to prevent this from
> > happening, and I focused on it because I thought that it would be
> > relatively uncontroversial.
>
> Actually, US Copyright is intentionally structured to allow
> critique. That's because American discourse has a tradition of
> open critique being a good thing. Art, literature, science, politics
> all have a flourishing community based on public critique.
Actually, the DMCA has provisions that undermine certain aspects of fair
use. But IANAL and I don't want to turn this into a discussion about
copyright law. I have already conceded that posting my code was
probably not illegal.
> For instance, I didn't agree with the original critique of your
> define-class. I'm not sure I'd use it, but I did see some things I
> like. If the debate had gone on, it could have brought up different
> points of view and taught us all something, because you made choices
> writing your code for reasons which someone else might not see
> immediately.
Except for two things: one, this was not code that I would want to use
as a starting point for a debate. It's old code. Some of it goes back
20 years to when I was young and foolish. I didn't want to keep
responding with, "I know, I know, when I get time I'll fix that." Two,
many of the objections to my code are ideological, not technical, and I
was not (and am not) in the mood to get into an ideological debate.
> Someone emailing you privately could produce a dialog benefiting you
> and the poster, but nobody else would learn from it, nor could their
> experiences help you.
Yes, that is unfortunate.
> It's certainly your prerogative not to post code you don't feel is
> worth the effort defending. (I've got a ton of stuff at home like
> that.) But I wanted to try to explain why people may have felt
> differently about critique; to me, it's not a matter of personal
> courtesy, because it's about the code, not the person.
I think of this more as professional rather than personal courtesy.
There are benefits to being able to share rough drafts without fear of
having them held to the same standard as something presented as a
finished work. And I think that the whole community suffers if people
think (as I believe many do) that the only way to avoid suffering the
full brunt of c.l.l. critiques is to keep their work to themselves.
E.
Erann Gat <·········@flownet.com> writes:
> I live in a community with a homeowner's association. Recently the HOA
> board, in an effort to curb speeding on neighborhood streets, started
> putting up speed bumps. Only a small minority of the residents actually
> speed, and the board knows it. (In fact, this is manifestly true,
> because if everyone wanted to speed they'd elect a board that would
> permit speeding.) But putting up speed bumps is (the board believes)
> the only effective means available to curb speeding.
>
> So the board doesn't "blame everyone" in the sense of believing that
> everyone is culpable. Nonetheless, they put up speed bumps (for
> everyone) because they believe (with some justification) that (some)
> members of the community cannot be trusted to obey the posted speed
> limits. It is a most unfortunate and annoying situation.
This happened in a community near me. Not only did they put up speed
bumps, but they took a straight section of road and intentionally made
S curves in it.
Unfortunately, the actual recorded speed *increased* after these
changes were made.
The politicians solution? We need *more* speed bumps....
"Erann Gat" <·········@flownet.com> wrote in message
····································@nntp1.jpl.nasa.gov...
> In article <·············@franz.com>, Duane Rettig <·····@franz.com>
> wrote:
> I live in a community with a homeowner's association. Recently the HOA
> board, in an effort to curb speeding on neighborhood streets, started
> putting up speed bumps. Only a small minority of the residents actually
> speed, and the board knows it. (In fact, this is manifestly true,
> because if everyone wanted to speed they'd elect a board that would
> permit speeding.) But putting up speed bumps is (the board believes)
> the only effective means available to curb speeding.
As a side issue, it also slows down emergency services. Austin, TX has been
removing such speed bumps for that very reason. The HOA may be liable for
the delay of emergency services, and should probably be apprised of that
potential liability.
Sometimes impacting everyone to correct the problems of a few is a bad idea.
Erann Gat wrote:
>
> P.S. Just to be clear, the issue for me personally is not so much
> copyright per se as it is publishing a highly negative critique.
Now here is the crux of the matter. Someone critiquing my code
does not make me angry, I try to understand what they are saying
and try to improve my next version. I have written a lot of code
that has been formally reviewed for commercial purposes. It can be
a disorienting (and deflating) process sometimes, but I distance myself
from my code. So I do not understand your anger as I do not
feel it. I was not disparaging your contribution of functional
code, I was just being honest about what went through my mind (in
a very unfiltered manner) when it comes to any code submitted
for Lisp standardization (which was in response to a previous
poster's question). Code that has to exist within a community
of people.
If you cannot live with my perspective and a time comes to
extend the CL standard, maybe I should just not bother participating
if it will piss you off.
Wade
Wade Humeniuk wrote:
> If you cannot live with my perspective and a time comes to
> extend the CL standard, maybe I should just not bother participating
> if it will piss you off.
Hear, hear!
If you think you're making a threat here, rather than a promise that
we'll gleefully hold you to, you've grossly misread the needs of the
other participants in this process.
I've refrained on commenting on your gratuitous mugging of Erann's code,
but now that you've brought the topic back around to the process at
hand, I hope we can consider the above your final, definitive comments.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> Hear, hear!
>
> If you think you're making a threat here, rather than a promise that
> we'll gleefully hold you to, you've grossly misread the needs of the
> other participants in this process.
>
Unlike you, my ego is not inflated. I know my place in things.
> I've refrained on commenting on your gratuitous mugging of Erann's code,
> but now that you've brought the topic back around to the process at
> hand, I hope we can consider the above your final, definitive comments.
>
Is it your last comment?
Wade
Cameron MacKinnon <··········@clearspot.net> writes:
> If you think you're making a threat here, rather than a promise that
> we'll gleefully hold you to, you've grossly misread the needs of the
> other participants in this process.
To whom do you refer as "we" here?
-dan
--
"please make sure that the person is your friend before you confirm"
In article <····················@edtnps84>,
Wade Humeniuk <········@telus.delete.net> wrote:
> Erann Gat wrote:
>
>
> >
> > P.S. Just to be clear, the issue for me personally is not so much
> > copyright per se as it is publishing a highly negative critique.
>
> Now here is the crux of the matter. Someone critiquing my code
> does not make me angry, I try to understand what they are saying
> and try to improve my next version.
Normally I would agree. But two things made this situation different.
First, I already knew the code had problems. As I've already said
several times, that was the main reason I didn't want to publish it in
the first place. And second, many of your critiques were matters of
stylistic opinion which have been rehashed many times and which I also
did not want to get embroiled in a discussion about.
But it was actually not the critique per se that angered me, it was the
fact that you made it public against my expressed wishes (not very well
expressed I will grant). If you'd sent me the critique via email
instead my response would have been very different.
> So I do not understand your anger
Does the above explanation help? I am only responding to help clarify
the situation. As far as I'm concerned this is water under the bridge.
> I was just being honest about what went through my mind (in
> a very unfiltered manner) when it comes to any code submitted
> for Lisp standardization (which was in response to a previous
> poster's question). Code that has to exist within a community
> of people.
Yes, except this code wasn't submitted as a candidate for
standardization. To the contrary, it was published to illustrate how
hard it is to make code suitable for standardization.
> If you cannot live with my perspective and a time comes to
> extend the CL standard, maybe I should just not bother participating
> if it will piss you off.
I have no objection in general to you (or anyone else) voicing your
opinions.
E.
Erann Gat <·········@flownet.com> writes:
> P.S. Just to be clear, the issue for me personally is not so much
> copyright per se as it is publishing a highly negative critique.
Cool! I'll have to remember that trick for when someone criticizes my
research. ("no fair casting aspersions on my data, it's copyright").
Since it would appear that in fact no Intellectual Property violation
was committed by any Lisper, it would be nice if we (Lispers) could
obtain a retraction. "My assertion that Lispers could not be trusted
to respect intellectual property was not supported by the evidence I
advanced; I apologise for making it" would be fine, at least for me.
As for insulating yourself against the possibility of negative
criticism, that indeed is your prerogative to ask for in the case of
code you publish: make your wishes clear(er) in future! (or don't
publish anything).
Sheesh.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
[Off Topic]
Erann Gat <·········@flownet.com> wrote in message
news:<·······························@nntp1.jpl.nasa.gov>...
> I live in a community with a homeowner's association. Recently the HOA
> board, in an effort to curb speeding on neighborhood streets, started
> putting up speed bumps. Only a small minority of the residents actually
> speed, and the board knows it. (In fact, this is manifestly true, because
> if everyone wanted to speed they'd elect a board that would permit
> speeding.) But putting up speed bumps is (the board believes) the only
> effective means available to curb speeding.
Happily, no speedbumps here. My HOA asked (pleaded?) with people to stop
speeding, in the newsletter, and when that didn't work to their satisfaction,
they invited (paid?) a police officer to come over for a few days and hand out
speeding tickets. That appears to've solved the problem.
How this applies to the situation here is left as an exercise for the reader
('cause I can't see how it does :).
-- Larry Clapp
* Erann Gat <·········@flownet.com>:
> In article <·························@hagbard.davep.org>,
> Dave Pearson <··········@davep.org> wrote:
>
> > * Erann Gat <·········@flownet.com>:
> >
> > > I have for the moment removed the code from the Web, since apparently
> > > Lispers cannot be trusted to respect intellectual property rights.
> >
> > One person does something that violates your licence and you blame every
> > Lisp programmer.
>
> Not so. "Blame" implies culpability and responsibility. I didn't ascribe
> responsibility to anyone but the perpetrator.
Ok, fine, "blame" is the wrong word then, I'm happy to withdraw it. So how
should one read the "Lispers cannot be trusted..." part?
> > What did I do wrong?
>
> Well, for starters, you're trying to blame (and I use that word advisedly)
> me for something I didn't do.
Actually I'm trying to work out why "Lispers cannot be trusted to respect
intellectual property rights" (but I suspect you knew that). On the surface
that looks like quite a sweeping generalisation.
--
Dave Pearson
http://www.davep.org/lisp/
In article <·························@hagbard.davep.org>,
Dave Pearson <··········@davep.org> wrote:
> * Erann Gat <·········@flownet.com>:
>
> > In article <·························@hagbard.davep.org>,
> > Dave Pearson <··········@davep.org> wrote:
> >
> > > * Erann Gat <·········@flownet.com>:
> > >
> > > > I have for the moment removed the code from the Web, since apparently
> > > > Lispers cannot be trusted to respect intellectual property rights.
> > >
> > > One person does something that violates your licence and you blame every
> > > Lisp programmer.
> >
> > Not so. "Blame" implies culpability and responsibility. I didn't ascribe
> > responsibility to anyone but the perpetrator.
>
> Ok, fine, "blame" is the wrong word then, I'm happy to withdraw it. So how
> should one read the "Lispers cannot be trusted..." part?
>
> > > What did I do wrong?
> >
> > Well, for starters, you're trying to blame (and I use that word advisedly)
> > me for something I didn't do.
>
> Actually I'm trying to work out why "Lispers cannot be trusted to respect
> intellectual property rights" (but I suspect you knew that). On the surface
> that looks like quite a sweeping generalisation.
It is indeed a sweeping generalization, but making a sweeping
generalization and ascribing blame are two completely different things.
Let me rephrase my sweeping generalization now that I am not quite so
hopping mad as I was when I wrote the statement in question.
There is a significant population of the Lisp community with which I
have fundamental differences about numerous issues, including (but by no
means limited to) respect for intellectual property rights. This is not
news. The manifestations of some of those differences are, I am given
to understand, legendary.
However, notwithstanding recurring insistence from some quarters to the
contrary, while I have always held (and continue to hold) hope, I do not
and never have held any *expectation* (in the sense of ascribing
responsibility, as opposed to the sense of trying to predict the future)
that people will change their behavior to conform to my beliefs. I have
always defended and will always continue to defend the rights of people
to do and say whatever they want here on c.l.l. (and anywhere else for
that matter). The only way to preserve my right to say what I want to
say is to defend the right of everyone else to say what they want to
say, no matter how much I may disagree.
My original visceral reaction to seeing my code cut-and-pasted on c.l.l.
was that it was an illegal act. Upon more sober reflection I no longer
believe this. But (and this is important) that is beside the point. My
hope was that what would prevent people from passing my code around
would be not the force of the law but simply respect for my wishes as
expressed in my license. Despite my long history of differences with
the Lisp community on a great many things I thought that there was
enough residual mutual respect for people to honor those terms simply
because I asked them to. I was shocked and dismayed when I was shown in
no uncertain terms that I was wrong.
Now, quite to the contrary to your assertion that I blame the entire
Lisp community for this unfortunate incident, I actually accept some of
the blame myself. The license terms were not in every source file, they
were just in a Readme file, and it is not necessarily reasonable to
expect everyone to look at a file just because it happens to be called
Readme. I certainly don't always look at the Readme. (I do think it is
reasonable to expect people to make some attempt to determine the terms
under which they have received a piece of code before they publish it on
Usenet rather than just assume it's GPL or public domain or whatever,
but this may be just another issue on which the Lisp community and I
will have to agree to disagree.)
So, to recount once again the circumstances that led me to publish this
code in the first place, it was in the context of a discussion about
standards, one of many recurring issues on which I am at perpetual
loggerheads with many people here on c.l.l. The salient part of the
discussion can be found here:
http://groups.google.com/groups?selm=gNOSPAMat-E78564.19300506052004%40nn
tp1.jpl.nasa.gov
If you go back and read that you will see that I published this code FOR
THE EXPRESS PURPOSE of making the point that TAKING CODE THAT IS USEFUL
FOR THE AUTHOR AND MAKING IT SUITABLE FOR PUBLICATION REQUIRES EFFORT.
I did not make that effort, and I'd say the results resoundingly
vindicate the point I was trying to make (a little too resoundingly
perhaps). And now, the point having been made, I am simply going back
to the previous situation until making the requisite efforts rolls to
the top of my priority queue. (Don't hold your breath.)
So you see, what I have done is not "blame everyone." It is, in fact,
exactly the opposite. I am accepting responsibility for my part in this
debacle, and I am taking what actions are within my power to take to
prevent it from happening again.
And it comes as no surprise to me at all that there are people here who
don't get that. There seem to be people who really don't get it when it
comes to intellectual property rights, who believe that anything on the
Internet is Fair Game, and not only that, but who believe that when
people take steps to protect their intellectual property (as I have
done) that they have done something bad, that they are "making sweeping
generalizations" or "blaming everyone" or some such thing. For some
unfathomable reasons some people actually seem to feel a sense of
entitlement, that I have some kind of obligation to publish my code
today simply because I chose to publish it yesterday.
So this is just one more example of where I have fundamental differences
with certain members of this community. To my way of thinking, my
publishing the code was a COURTESY, and the ONLY appropriate *public*
response is, "Thank you for making this code available for free." It's
got nothing to do with copyright or the law. It's just basic common
courtesy of the sort that I would have expected everyone to learn in the
second grade. But that's just my opinion, and my opinion doesn't count
any more than anyone else's -- except under one special circumstance.
Figuring out what that is is left as an exercise.
E.
* Erann Gat <·········@flownet.com>:
> In article <·························@hagbard.davep.org>,
> Dave Pearson <··········@davep.org> wrote:
>
> > Actually I'm trying to work out why "Lispers cannot be trusted to
> > respect intellectual property rights" (but I suspect you knew that). On
> > the surface that looks like quite a sweeping generalisation.
>
> It is indeed a sweeping generalization, but making a sweeping
> generalization and ascribing blame are two completely different things.
You did see where I acknowledged that "blame" was probably clumsy wording on
my part, didn't you?
> Now, quite to the contrary to your assertion that I blame the entire Lisp
> community for this unfortunate incident, [SNIP]
Ahh, perhaps you didn't see it after all.
> http://groups.google.com/groups?selm=gNOSPAMat-E78564.19300506052004%40nn
> tp1.jpl.nasa.gov
>
> If you go back and read that you will see that I published this code FOR
> THE EXPRESS PURPOSE of making the point that TAKING CODE THAT IS USEFUL
> FOR THE AUTHOR AND MAKING IT SUITABLE FOR PUBLICATION REQUIRES EFFORT.
I actually went and had a look at your code *and* even read the README and
noted the terms of your licence (not to mention the fact that I've published
a lot of code over the years and understand and appreciate your concerns).
My possibly clumsy wording aside, do you see why I might have asked the
question I asked?
Perhaps you could concentrate less on the clumsy wording and consider the
question I asked? Given this one visible alleged ignoring of your licence,
how does someone conclude that "Lispers cannot be trusted to respect
intellectual property rights". I'm genuinely curious about that line of
thinking.
--
Dave Pearson
http://www.davep.org/lisp/
In article <·························@hagbard.davep.org>,
Dave Pearson <··········@davep.org> wrote:
> * Erann Gat <·········@flownet.com>:
>
> > In article <·························@hagbard.davep.org>,
> > Dave Pearson <··········@davep.org> wrote:
> >
> > > Actually I'm trying to work out why "Lispers cannot be trusted to
> > > respect intellectual property rights" (but I suspect you knew that). On
> > > the surface that looks like quite a sweeping generalisation.
> >
> > It is indeed a sweeping generalization, but making a sweeping
> > generalization and ascribing blame are two completely different things.
>
> You did see where I acknowledged that "blame" was probably clumsy wording on
> my part, didn't you?
I did.
> Perhaps you could concentrate less on the clumsy wording and consider the
> question I asked? Given this one visible alleged ignoring of your licence,
> how does someone conclude that "Lispers cannot be trusted to respect
> intellectual property rights".
You did see where I said that that statement was written in a moment of
anger and so I restated it, didn't you?
You expect me to extend you to take note of your retractions and not
hold you to your original statements, and yet you refuse to extend me
the same courtesy.
> I'm genuinely curious about that line of thinking.
If that's really true (which I doubt) then you need to go back and read
what I wrote with more care and introspection.
E.
In article <·······························@nntp1.jpl.nasa.gov>,
Erann Gat <·········@flownet.com> wrote:
> You expect me to extend you to take note of your retractions and not
Just in case it wasn't obvious, that should have read "You expect me to
take note..."
E.
* Erann Gat <·········@flownet.com>:
> In article <·························@hagbard.davep.org>,
> Dave Pearson <··········@davep.org> wrote:
>
> > Perhaps you could concentrate less on the clumsy wording and consider
> > the question I asked? Given this one visible alleged ignoring of your
> > licence, how does someone conclude that "Lispers cannot be trusted to
> > respect intellectual property rights".
>
> You did see where I said that that statement was written in a moment of
> anger and so I restated it, didn't you?
Yes, I read something about you being "hopping mad", but what followed it
didn't seem to explain what you'd said about "Lispers", it only appeared to
talk about people who violate licence agreements.
> You expect me to extend you to take note of your retractions and not hold
> you to your original statements, and yet you refuse to extend me the same
> courtesy.
Was that supposed to be a question?
> > I'm genuinely curious about that line of thinking.
>
> If that's really true (which I doubt) then you need to go back and read
> what I wrote with more care and introspection.
Why do you doubt it? That seems quite hostile and I see no need for such
hostility.
--
Dave Pearson
http://www.davep.org/lisp/
In article <·························@hagbard.davep.org>,
Dave Pearson <··········@davep.org> wrote:
> * Erann Gat <·········@flownet.com>:
>
> > In article <·························@hagbard.davep.org>,
> > Dave Pearson <··········@davep.org> wrote:
> >
> > > Perhaps you could concentrate less on the clumsy wording and consider
> > > the question I asked? Given this one visible alleged ignoring of your
> > > licence, how does someone conclude that "Lispers cannot be trusted to
> > > respect intellectual property rights".
> >
> > You did see where I said that that statement was written in a moment of
> > anger and so I restated it, didn't you?
>
> Yes, I read something about you being "hopping mad", but what followed it
> didn't seem to explain what you'd said about "Lispers", it only appeared to
> talk about people who violate licence agreements.
Then you obviously made no effort to understand what I wrote.
> > You expect me to extend you to take note of your retractions and not hold
> > you to your original statements, and yet you refuse to extend me the same
> > courtesy.
>
> Was that supposed to be a question?
No.
> > > I'm genuinely curious about that line of thinking.
> >
> > If that's really true (which I doubt) then you need to go back and read
> > what I wrote with more care and introspection.
>
> Why do you doubt it?
Because if you were genuinely curious then you would have followed the
advice I gave you.
> That seems quite hostile
Don't confuse annoyance with hostility (unless you want to turn it into
a self-fulfilling prophecy).
E.
* Erann Gat <·········@flownet.com>:
> In article <·························@hagbard.davep.org>,
> Dave Pearson <··········@davep.org> wrote:
>
> > Yes, I read something about you being "hopping mad", but what followed
> > it didn't seem to explain what you'd said about "Lispers", it only
> > appeared to talk about people who violate licence agreements.
>
> Then you obviously made no effort to understand what I wrote.
I'm more than happy to accept the suggestion that I didn't understand what
you'd written, but why do you want to portray that as a wilful lack of
understanding? What purpose does that serve?
> > > You expect me to extend you to take note of your retractions and not
> > > hold you to your original statements, and yet you refuse to extend me
> > > the same courtesy.
> >
> > Was that supposed to be a question?
>
> No.
Ok, in that case you're mistaken about my motivation. I refused nothing of
the sort.
> > > If that's really true (which I doubt) then you need to go back and
> > > read what I wrote with more care and introspection.
> >
> > Why do you doubt it?
>
> Because if you were genuinely curious then you would have followed the
> advice I gave you.
What advice are you referring to?
> > That seems quite hostile
>
> Don't confuse annoyance with hostility (unless you want to turn it into a
> self-fulfilling prophecy).
Does confusing failure to understand with a desire to fail to understand
also count as a self-fulfilling prophecy?
--
Dave Pearson
http://www.davep.org/lisp/
In article <·························@hagbard.davep.org>,
Dave Pearson <··········@davep.org> wrote:
> * Erann Gat <·········@flownet.com>:
>
> > In article <·························@hagbard.davep.org>,
> > Dave Pearson <··········@davep.org> wrote:
> >
> > > Yes, I read something about you being "hopping mad", but what followed
> > > it didn't seem to explain what you'd said about "Lispers", it only
> > > appeared to talk about people who violate licence agreements.
> >
> > Then you obviously made no effort to understand what I wrote.
>
> I'm more than happy to accept the suggestion that I didn't understand what
> you'd written, but why do you want to portray that as a wilful lack of
> understanding?
Because that's pretty clearly what it is. (See below.)
> What purpose does that serve?
Perhaps it will motivate you to put forth a more sincere effort.
> > > > You expect me to extend you to take note of your retractions and not
> > > > hold you to your original statements, and yet you refuse to extend me
> > > > the same courtesy.
> > >
> > > Was that supposed to be a question?
> >
> > No.
>
> Ok, in that case you're mistaken about my motivation. I refused nothing of
> the sort.
Yes you did, and you continue to do so by insisting on answers to
counterfactual questions.
> > > > If that's really true (which I doubt) then you need to go back and
> > > > read what I wrote with more care and introspection.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >
> > > Why do you doubt it?
> >
> > Because if you were genuinely curious then you would have followed the
> > advice I gave you.
>
> What advice are you referring to?
All of it. (And just in case it isn't glaringly obvious, the fact that
you asked a question whose answer was written four lines above where you
were typing is just one of many indications that your lack of
understanding is willful.)
E.
* Erann Gat <·········@flownet.com>:
> In article <·························@hagbard.davep.org>,
> Dave Pearson <··········@davep.org> wrote:
>
> > I'm more than happy to accept the suggestion that I didn't understand
> > what you'd written, but why do you want to portray that as a wilful lack
> > of understanding?
>
> Because that's pretty clearly what it is. (See below.)
Oh give over Erann! It really isn't wilful, I can see how you might wish it
to be and I can see how, given that, you wouldn't want to hear otherwise,
but, really, is there any need to keep misrepresenting my motivations like
this?
> > Ok, in that case you're mistaken about my motivation. I refused nothing
> > of the sort.
>
> Yes you did, and you continue to do so by insisting on answers to
> counterfactual questions.
I'm not insisting on anything. You, on the other hand, keep insisting that
I'm somehow wilfully failing to understand what you'd written.
> > What advice are you referring to?
>
> All of it. (And just in case it isn't glaringly obvious, the fact that you
> asked a question whose answer was written four lines above where you were
> typing is just one of many indications that your lack of understanding is
> willful.)
It could be an indication of something far less negative. Can you imagine
that?
--
Dave Pearson
http://www.davep.org/lisp/
Dave Pearson <··········@davep.org> writes:
>> Don't confuse annoyance with hostility (unless you want to turn it into a
>> self-fulfilling prophecy).
>
> Does confusing failure to understand with a desire to fail to understand
> also count as a self-fulfilling prophecy?
Why do you say that confusing failure to understand with a desire to
fail to understand also count as a self-fulfilling prophecy? Maybe
your plans have something to do with this.
-dan
--
"please make sure that the person is your friend before you confirm"
* Daniel Barlow <···@telent.net>:
> Dave Pearson <··········@davep.org> writes:
>
> > Does confusing failure to understand with a desire to fail to understand
> > also count as a self-fulfilling prophecy?
>
> Why do you say that confusing failure to understand with a desire to fail
> to understand also count as a self-fulfilling prophecy? Maybe your plans
> have something to do with this.
Is it because do I say that confusing failure to understand with a desire to
fail to understand also count as a self fulfilling prophecy maybe my plans
have something to do with this that you came to me?
--
Dave Pearson
http://www.davep.org/lisp/
Dave Pearson <··········@davep.org> writes:
> * Erann Gat <·········@flownet.com>:
>
> > In article <·························@hagbard.davep.org>,
> > Dave Pearson <··········@davep.org> wrote:
> >
> > > Perhaps you could concentrate less on the clumsy wording and
> > > consider the question I asked? Given this one visible alleged
> > > ignoring of your licence, how does someone conclude that
> > > "Lispers cannot be trusted to respect intellectual property
> > > rights".
> >
> > You did see where I said that that statement was written in a
> > moment of anger and so I restated it, didn't you?
>
> Yes, I read something about you being "hopping mad", but what
> followed it didn't seem to explain what you'd said about "Lispers",
> it only appeared to talk about people who violate licence
> agreements.
Perhaps I should have been following this thread a little closer, and
I am really worried about Daniel Barlow apparently thinking that you
are nuts (Daniel Barlow is usually right), but just in case you want
to focus on this "Erann Gat being hopping mad"-part, I think you're
onto something. Yes, he really is. Ask him, for instance, why the
government is prescribing the price for wheat. He will tell you that
it does so in an attempt to keep the price "stable" (his word). This
is a statement that is indeed so fucking mad that not even John Kerry
would make such a stupid claim. Really. Just ask him.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x7E4651AD
···@cartan.de (Nils Gösche) writes:
> to focus on this "Erann Gat being hopping mad"-part, I think you're
> onto something. Yes, he really is. Ask him, for instance, why the
> government is prescribing the price for wheat. He will tell you that
> it does so in an attempt to keep the price "stable" (his word). This
> is a statement that is indeed so fucking mad that not even John Kerry
> would make such a stupid claim. Really. Just ask him.
After a phone call, John Kerry explained that he did in fact vote for
price supports but that was before he didn't.
Then he went on a minor rant about dairy products and how he never
really met Jane Fonda. It didn't make much sense at the time, so I
just nodded my head.
That doesn't go over well on the phone.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Nils G�sche wrote:
> Perhaps I should have been following this thread a little closer, and
> I am really worried about Daniel Barlow apparently thinking that you
> are nuts (Daniel Barlow is usually right), but just in case you want
> to focus on this "Erann Gat being hopping mad"-part, I think you're
> onto something. Yes, he really is. Ask him, for instance, why the
> government is prescribing the price for wheat. He will tell you that
> it does so in an attempt to keep the price "stable" (his word). This
> is a statement that is indeed so fucking mad that not even John Kerry
> would make such a stupid claim. Really. Just ask him.
Well, that officially adds Erann to my personal Pantheon. I figure
anyone who, like David Touretzky, has attracted a following of
disaffected wingnuts who post offtopic flames at the mention of his name
must be doing something right.
--
Cameron MacKinnon
Toronto, Canada
In article <······················@golden.net>, Cameron MacKinnon
<··········@clearspot.net> wrote:
> Well, that officially adds Erann to my personal Pantheon. I figure
> anyone who, like David Touretzky, has attracted a following of
> disaffected wingnuts who post offtopic flames at the mention of his name
> must be doing something right.
Nils is not a disaffected wingnut; he's merely pointing out that Erann
is a douchebag, which is true. The specific example was offtopic, but
the general point stands.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Are you aiming to secure Erann a better spot in the Pantheon by adding
yourself to his train of disaffected wingnuts? People who inject
bizarre, totally offtopic personal observations into discussions are
either cute (if they're 4 or younger), poorly parented (9 or younger) or
pathological.
Why would I care what Erann's opinions on agricultural policy are? When
I weigh the evidence that he was hired by NASA (twice) and Google versus
a few tens of seconds of effort by a few bored souls on Usenet, on whose
side do you suppose the balance descends?
--
Cameron MacKinnon
Toronto, Canada
In article <······················@golden.net>, Cameron MacKinnon
<··········@clearspot.net> wrote:
> Are you aiming to secure Erann a better spot in the Pantheon by adding
> yourself to his train of disaffected wingnuts? People who inject
> bizarre, totally offtopic personal observations into discussions are
> either cute (if they're 4 or younger), poorly parented (9 or younger) or
> pathological.
Nils chose a bad example, but since the subject was "ad hominem attacks
on Erann", it was indeed on-subject. And I'm not a disaffected wingnut,
nor have I ever posted to this effect before. A quick check of my
homepage would reveal that I'm a lisper. A quick google search on my
name would confirm that too. I simply haven't been following the
c.l.landfill recently, but since Nils mentioned it on IRC, I thought
I'd jump in.
If you're determined to hero-worship, I might as well provide you with
a really off-topic personality attack: KMP is a complete and utter
jackass. There. Now I'm really a disaffected wingnut.
> Why would I care what Erann's opinions on agricultural policy are? When
> I weigh the evidence that he was hired by NASA (twice) and Google versus
> a few tens of seconds of effort by a few bored souls on Usenet, on whose
> side do you suppose the balance descends?
I'm not a bored soul. Neither did I question the fact that he was hired
by JPL and Google. I simply stated that he was a douchebag, which is an
ad hominem personality attack unrelated to his qualifications as a
programmer.
Good day.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> name would confirm that too. I simply haven't been following the
> c.l.landfill recently, but since Nils mentioned it on IRC, I thought
> I'd jump in.
I think you need to choose between ragging on c.l.l and despoiling it --
no fair doing both.
>
> If you're determined to hero-worship, I might as well provide you with
> a really off-topic personality attack: <gratuitous nonsense deleted>
Along with Nils's surprising outburst, I am not sure I have seen
Lispniks behaving so badly towards other Lispniks in quite a while. You
must have the wrong style guide; that simply is not how we act around
here. You and Nils have with your tantrums done nothing but make the
community think less of yourselves.
kenny
Brian Mastenbrook wrote:
>
> If you're determined to hero-worship, I might as well provide you with
> a really off-topic personality attack: KMP is a complete and utter
> jackass. There. Now I'm really a disaffected wingnut.
>
Hmm....., reverse psychology.
Wade
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Nils G�sche wrote:
> > Perhaps I should have been following this thread a little closer, and
> > I am really worried about Daniel Barlow apparently thinking that you
> > are nuts (Daniel Barlow is usually right), but just in case you want
> > to focus on this "Erann Gat being hopping mad"-part, I think you're
> > onto something. Yes, he really is. Ask him, for instance, why the
> > government is prescribing the price for wheat. He will tell you that
> > it does so in an attempt to keep the price "stable" (his word). This
> > is a statement that is indeed so fucking mad that not even John Kerry
> > would make such a stupid claim. Really. Just ask him.
>
> Well, that officially adds Erann to my personal Pantheon. I figure
> anyone who, like David Touretzky, has attracted a following of
> disaffected wingnuts who post offtopic flames at the mention of his name
> must be doing something right.
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Nils G�sche wrote:
> > Perhaps I should have been following this thread a little closer, and
> > I am really worried about Daniel Barlow apparently thinking that you
> > are nuts (Daniel Barlow is usually right), but just in case you want
> > to focus on this "Erann Gat being hopping mad"-part, I think you're
> > onto something. Yes, he really is. Ask him, for instance, why the
> > government is prescribing the price for wheat. He will tell you that
> > it does so in an attempt to keep the price "stable" (his word). This
> > is a statement that is indeed so fucking mad that not even John Kerry
> > would make such a stupid claim. Really. Just ask him.
>
> Well, that officially adds Erann to my personal Pantheon. I figure
> anyone who, like David Touretzky, has attracted a following of
> disaffected wingnuts who post offtopic flames at the mention of his name
> must be doing something right.
What could that be? Mailing porn letters to harass a lady, or having
bomb instructions on his website, or degrading a religion through
porn, or denying somebody her right to freedom of speech, or forcing
psychiatry on people who don't want or need it? Speak, Cameron, what
does the porn and bomb instruction guy Dave Touretzky right?
You find it off topic to post about the character of a person on
comp.lang.lisp?
I don't agree, as a rat guy like TouRATzky is also no Einstein on
other subjects or the topic of comp.lang.lisp.
Barbara Schwarz
················@myway.com (Barbara Schwarz) writes:
> You find it off topic to post about the character of a person on
> comp.lang.lisp?
Yes. Go away now.
Alain Picard <············@memetrics.com> wrote in message news:<··············@memetrics.com>...
> ················@myway.com (Barbara Schwarz) writes:
>
>
> > You find it off topic to post about the character of a person on
> > comp.lang.lisp?
>
> Yes. Go away now.
I go away when I want. But interesting is that character doesn't count
here, actually, no place I want to stick around. But I come by
whenever I please. If you have a problem with free speech, move on
another planet.
Barbara Schwarz
>>>>> "BS" == Barbara Schwarz <················@myway.com> writes:
BS> I go away when I want. But interesting is that character
BS> doesn't count here, actually, no place I want to stick
BS> around. But I come by whenever I please. If you have a problem
BS> with free speech, move on another planet.
You know, there's some irony in claiming free speech as a shield, when
it is used to scream in self-righteous indignation about what other
people have to say.
On the other hand, filtering is easy, and bandwidth cheap. Rant on...
--
"Some people's idea of free speech is that they are free to say
anything they like, but if anyone says anything back, that is an
outrage." -- Winston Churchill
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Nils G�sche wrote:
> > Perhaps I should have been following this thread a little closer, and
> > I am really worried about Daniel Barlow apparently thinking that you
> > are nuts (Daniel Barlow is usually right), but just in case you want
> > to focus on this "Erann Gat being hopping mad"-part, I think you're
> > onto something. Yes, he really is. Ask him, for instance, why the
> > government is prescribing the price for wheat. He will tell you that
> > it does so in an attempt to keep the price "stable" (his word). This
> > is a statement that is indeed so fucking mad that not even John Kerry
> > would make such a stupid claim. Really. Just ask him.
>
> Well, that officially adds Erann to my personal Pantheon. I figure
> anyone who, like David Touretzky, has attracted a following of
> disaffected wingnuts who post offtopic flames at the mention of his name
> must be doing something right.
What could that be? Mailing porn letters to harass a lady, or having
bomb instructions on his website, or degrading a religion through
porn, or denying somebody her right to freedom of speech, or forcing
psychiatry on people who don't want or need it? Speak, Cameron, what
does the porn and bomb instruction guy Dave Touretzky right?
You find it off topic to post about the character of a person on
comp.lang.lisp?
I don't agree, as a rat guy like TouRATzky is also no Einstein on
other subjects or the topic of comp.lang.lisp.
Barbara Schwarz
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Nils G�sche wrote:
> > Perhaps I should have been following this thread a little closer, and
> > I am really worried about Daniel Barlow apparently thinking that you
> > are nuts (Daniel Barlow is usually right), but just in case you want
> > to focus on this "Erann Gat being hopping mad"-part, I think you're
> > onto something. Yes, he really is. Ask him, for instance, why the
> > government is prescribing the price for wheat. He will tell you that
> > it does so in an attempt to keep the price "stable" (his word). This
> > is a statement that is indeed so fucking mad that not even John Kerry
> > would make such a stupid claim. Really. Just ask him.
>
> Well, that officially adds Erann to my personal Pantheon. I figure
> anyone who, like David Touretzky, has attracted a following of
> disaffected wingnuts who post offtopic flames at the mention of his name
> must be doing something right.
What could that be? Mailing porn letters to harass a lady, or having
bomb instructions on his website, or degrading a religion through
porn, or denying somebody her right to freedom of speech, or forcing
psychiatry on people who don't want or need it? Speak, Cameron, what
does the porn and bomb instruction guy Dave Touretzky right?
You find it off topic to post about the character of a person on
comp.lang.lisp?
I don't agree, as a rat guy like TouRATzky is also no Einstein on
other subjects or the topic of comp.lang.lisp.
Barbara Schwarz
Cameron MacKinnon <··········@clearspot.net> writes:
> Well, that officially adds Erann to my personal Pantheon.
Heh. Erann was involved with making Lisp successful in _space_.
That counts more than a thousand wankers spouting drivel on CLL
for a thousand years.
The point isn't that he's always right (or wrong). The point
is that he's f*cking DONE something.
In article <····················@clgrps13>,
Wade Humeniuk <········@telus.delete.net> wrote:
Leaving aside for the moment the fact that the code that Wade cut and
pasted was explicitly NOT licensed for redistribution, here, for the
record, are some responses to Wade's critique:
> (define-class (locale named-object)
> parent
> (name (gentemp "L"))
> (namespaces { value {} function {} } ))
...
> (define-class (module locale)
> (readtable (copy-readtable)))
>
> Hmmmmmmmmmmmmmmmmm, different syntax,
The syntax for DEFINE-CLASS is:
(define-class (class superclass ...) (slot initform type) ...)
If there are no superclasses then parens around (class) may be omitted.
Likewise, if there is neither an initform nor a type then the parens
around (slot initform type) may be omitted.
DEFINE-CLASS defines the class, a function named MAKE-class which does
the obvious thing, and accessors named class-slot for each slot. (It
does a few other things as well, but if you want to know what those are
you'll have to reverse-engineer the code. This, by the way, is one of
the important differences between a standard and an implementation. In
the absence of a standard you have no way of knowing whether or not you
are supposed to be able to rely on any additional features that the
implementation seems to have.)
> I guess I will have to learn a new class system
No, you'll just have to ask me to document DEFINE-CLASS.
(It never ceases to astonish me how frequently one encounters people who
object to things because they'll have to learn something new. Oh, the
horror!)
> Wow, yikes, if there is a problem with this code, I am going to have
> to learn something. More work for me, yipeee! Am I getting the feeling
> here that he wants to make his code compatible with some Scheme system??
As I've said several times before, DEFINE-CLASS was modeled after
Oaklisp.
> Was something wrong with CLOS????? What????
I don't like the syntax for DEFCLASS. I can never remember where all
the parens are supposed to go.
The implication that putting a thin wrapper around DEFCLASS is a bad
thing to do seems to me at odds with the oft-touted feature of Lisp that
it is a "programmable programming language" and that its syntax can be
tailored to suit one's tastes.
But there are actually additional reasons for DEFINE-CLASS. If you look
at the code you will see that it also stores information about the class
in a portable way, making certain MOP-like operations possible in CL
implementations that lack a MOP implementation. Yes, it is possible to
do the same thing by shadowing DEFCLASS, but then your code has to parse
DEFCLASS syntax, making it even harder and more complicated to implement
than it is. And you're already complaining about how byzantine the code
is.
> If this was a released library I would give a thumbs down.
That is one of the reasons it isn't a released library (not that I ever
gave a rat's ass what you think).
> Not to mention
> that his define-method will prevent my LW editor from picking
> this any CLOS method in the defintions and changed definitions tab.
I'd say that's a defect in your editor. It will fail on *any* macro
that expands into a definition form. Or are you saying that macros
should never expand into definition forms?
> Erann is free to do whatever he wants. I know this code was Erann's
> private experimentation and he can do whatever he wants, and it was
> good of him to release it for others the see. And I am sure that if
> he ever released a library it would use defclass and defmethod, right?
Oh, you don't need to worry about my coding style. It's a pretty safe
bet that I won't be releasing any more code for public inspection any
time soon.
E.
In article <·······························@nntp1.jpl.nasa.gov>,
Erann Gat <·········@flownet.com> wrote:
>you'll have to reverse-engineer the code. This, by the way, is one of
>the important differences between a standard and an implementation. In
>the absence of a standard you have no way of knowing whether or not you
>are supposed to be able to rely on any additional features that the
>implementation seems to have.)
No, that's the difference between an implementation and a documented
interface.
>The implication that putting a thin wrapper around DEFCLASS is a bad
>thing to do seems to me at odds with the oft-touted feature of Lisp that
>it is a "programmable programming language" and that its syntax can be
>tailored to suit one's tastes.
That's because it's a bullshit feature, I suspect. Or rather, it's a
great feature for code writers, but a terrible feature for code
readers (who generally outnumber writers). The thing that both
attracts me to, and makes me wary of, Lisp is that it reminds me
highly of Perl, in that respect. I never felt so comfortable as when
I wrote Perl; I never felt so irritated as when I read someone else's
Perl. Whereas with Java, where there's one damn way to do everything,
I'm just mildly irritated all the time.
--
Mike Kozlowski
http://www.klio.org/mlk/
In article <············@reader2.panix.com>,
Mike Kozlowski <···@klio.org> wrote:
> In article <·······························@nntp1.jpl.nasa.gov>,
> Erann Gat <·········@flownet.com> wrote:
>
> >you'll have to reverse-engineer the code. This, by the way, is one of
> >the important differences between a standard and an implementation. In
> >the absence of a standard you have no way of knowing whether or not you
> >are supposed to be able to rely on any additional features that the
> >implementation seems to have.)
>
> No, that's the difference between an implementation and a documented
> interface.
True. Let me rephrase: standards are more useful when they take the
form of documented interfaces than when they take the form of reference
implementations.
> >The implication that putting a thin wrapper around DEFCLASS is a bad
> >thing to do seems to me at odds with the oft-touted feature of Lisp that
> >it is a "programmable programming language" and that its syntax can be
> >tailored to suit one's tastes.
>
> That's because it's a bullshit feature, I suspect.
Sorry, I don't feed trolls.
E.
Mike Kozlowski <···@klio.org> wrote in message news:<············@reader2.panix.com>...
> In article <·······························@nntp1.jpl.nasa.gov>,
> Erann Gat <·········@flownet.com> wrote:
>
> >The implication that putting a thin wrapper around DEFCLASS is a bad
> >thing to do seems to me at odds with the oft-touted feature of Lisp that
> >it is a "programmable programming language" and that its syntax can be
> >tailored to suit one's tastes.
>
> That's because it's a bullshit feature, I suspect. Or rather, it's a
> great feature for code writers, but a terrible feature for code
> readers (who generally outnumber writers). The thing that both
> attracts me to, and makes me wary of, Lisp is that it reminds me
> highly of Perl, in that respect. I never felt so comfortable as when
> I wrote Perl; I never felt so irritated as when I read someone else's
> Perl. Whereas with Java, where there's one damn way to do everything,
> I'm just mildly irritated all the time.
s/mildly/wildly/
I like the TIMTWATDI feature of Lisp and Perl. I suspect that feature
also exists to a lesser extent in Java.
I also like the fact that Lisp can support multiple paradigms.
What I don't understand is why you would complain about the feature
that probably puts Lisp on top of the heap as far as programming
languages go (if you can in fact name any one feature). Macros
clearly have major mojo. Why take that out of a language because some
people think it makes it harder to read? And why would code readers
out number code writers? Are you programming or not?
In my experience, all computer code in any language can be hard to
read. Complex algorithms are going to be complex by their very
nature. Esoteric algorithms won't be familiar. I guess that's why
they call it code.
I'm sorry I didn't grab Erann's code before it was yanked. I'm sure I
could have learned something from it. The posted bits looked quite
clever from what I could tell.
BTW, Google does not seem to honor cancel requests. Not all news
servers do.
Well, I sort of tend to agree here.
Apart from the sometime useful MAKE-<class> I find myself writing the
following over and over
(defclass foo (...) (...))
(defgeneric foo-p (x)
(:method ((x foo)) t)
(:method ((x t)) nil))
Having the FOO-P function generated automatically from DEFCLASS would be
nice indeed.
Cheers
Marco
Erann Gat wrote:
> In article <····················@clgrps13>,
> Wade Humeniuk <········@telus.delete.net> wrote:
>
> Leaving aside for the moment the fact that the code that Wade cut and
> pasted was explicitly NOT licensed for redistribution, here, for the
> record, are some responses to Wade's critique:
>
>
>>(define-class (locale named-object)
>> parent
>> (name (gentemp "L"))
>> (namespaces { value {} function {} } ))
>
> ...
>
>>(define-class (module locale)
>> (readtable (copy-readtable)))
>>
>>Hmmmmmmmmmmmmmmmmm, different syntax,
>
>
> The syntax for DEFINE-CLASS is:
>
> (define-class (class superclass ...) (slot initform type) ...)
>
> If there are no superclasses then parens around (class) may be omitted.
> Likewise, if there is neither an initform nor a type then the parens
> around (slot initform type) may be omitted.
>
> DEFINE-CLASS defines the class, a function named MAKE-class which does
> the obvious thing, and accessors named class-slot for each slot. (It
> does a few other things as well, but if you want to know what those are
> you'll have to reverse-engineer the code. This, by the way, is one of
> the important differences between a standard and an implementation. In
> the absence of a standard you have no way of knowing whether or not you
> are supposed to be able to rely on any additional features that the
> implementation seems to have.)
>
>
>>I guess I will have to learn a new class system
>
>
> No, you'll just have to ask me to document DEFINE-CLASS.
>
> (It never ceases to astonish me how frequently one encounters people who
> object to things because they'll have to learn something new. Oh, the
> horror!)
>
>
>
>>Wow, yikes, if there is a problem with this code, I am going to have
>>to learn something. More work for me, yipeee! Am I getting the feeling
>>here that he wants to make his code compatible with some Scheme system??
>
>
> As I've said several times before, DEFINE-CLASS was modeled after
> Oaklisp.
>
>
>>Was something wrong with CLOS????? What????
>
>
> I don't like the syntax for DEFCLASS. I can never remember where all
> the parens are supposed to go.
>
> The implication that putting a thin wrapper around DEFCLASS is a bad
> thing to do seems to me at odds with the oft-touted feature of Lisp that
> it is a "programmable programming language" and that its syntax can be
> tailored to suit one's tastes.
>
> But there are actually additional reasons for DEFINE-CLASS. If you look
> at the code you will see that it also stores information about the class
> in a portable way, making certain MOP-like operations possible in CL
> implementations that lack a MOP implementation. Yes, it is possible to
> do the same thing by shadowing DEFCLASS, but then your code has to parse
> DEFCLASS syntax, making it even harder and more complicated to implement
> than it is. And you're already complaining about how byzantine the code
> is.
>
>
>>If this was a released library I would give a thumbs down.
>
>
> That is one of the reasons it isn't a released library (not that I ever
> gave a rat's ass what you think).
>
>
>>Not to mention
>>that his define-method will prevent my LW editor from picking
>>this any CLOS method in the defintions and changed definitions tab.
>
>
> I'd say that's a defect in your editor. It will fail on *any* macro
> that expands into a definition form. Or are you saying that macros
> should never expand into definition forms?
>
>
>
>>Erann is free to do whatever he wants. I know this code was Erann's
>>private experimentation and he can do whatever he wants, and it was
>>good of him to release it for others the see. And I am sure that if
>>he ever released a library it would use defclass and defmethod, right?
>
>
> Oh, you don't need to worry about my coding style. It's a pretty safe
> bet that I won't be releasing any more code for public inspection any
> time soon.
>
> E.
In article <··················@typhoon.nyu.edu>,
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> Apart from the sometime useful MAKE-<class> I find myself writing the
> following over and over
>
>
> (defclass foo (...) (...))
>
> (defgeneric foo-p (x)
> (:method ((x foo)) t)
> (:method ((x t)) nil))
>
>
> Having the FOO-P function generated automatically from DEFCLASS would be
> nice indeed.
If you're using OO programming techniques, I wonder why you need to use
functions like this often enough to need short names for them? I'd
expect you to make use of method dispatch rather than frequent (if
(foo-p ...)...).
And if it's not so frequent, I think (typep ... 'foo) would be good
enough.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Friedrich Dominicus wrote:
> 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
In article <····················@clgrps13>,
Wade Humeniuk <········@telus.delete.net> wrote:
> Friedrich Dominicus wrote:
>
> > What does this mean?
>
> Oh, yes, one more thing. I was slightly pissed at Erann for
> dumping on Edi like that.
Excuse me? What are you referring to?
E.
On Fri, 07 May 2004 15:36:13 -0700, Erann Gat <·········@flownet.com> wrote:
> In article <··············@bird.agharta.de>, Edi Weitz <···@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.
[1] <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de>
wrote:
> On Fri, 07 May 2004 15:36:13 -0700, Erann Gat <·········@flownet.com> wrote:
>
> > In article <··············@bird.agharta.de>, Edi Weitz <···@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.
From: Friedrich Dominicus
Subject: Re: Modernizing Common Lisp
Date:
Message-ID: <873c6be3pp.fsf@fbigm.here>
Erann Gat <·········@flownet.com> writes:
> 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
--
Please remove just-for-news- to reply via e-mail.
Peter Seibel <·····@javamonkey.com> writes:
> 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.
I'm very grateful to Edi Weitz for having produced CL-PPCRE but I have
wished at times that it wasn't necessarily constrained by
compatability with Perl. For example, in a recent e-mail on the
development e-mailing list in which a user was discussing a port to
Genera on which he was working, one found the following:
2. You mentioned there are a couple of issues with the tests
due to different character encodings. Is there a short
sentence I could add to the README file like: "Note that
some tests will fail on Genera because characters like...
have encodings which differ from Perl's expectations?"
Return, Linefeed, and Tab. There are others, such as Back-Space
and Page, but I don't think they appeared in the tests.
I think its unfortunate, for example, that this is the case. But
<shrug> I still *love* having, for example, a regexp package with sexp
notation for the regular expressions.
On 01 Oct 2004 12:55:17 -0500, Damien Kick <······@email.mot.com> wrote:
> I'm very grateful to Edi Weitz for having produced CL-PPCRE but I
> have wished at times that it wasn't necessarily constrained by
> compatability with Perl. For example, in a recent e-mail on the
> development e-mailing list in which a user was discussing a port to
> Genera on which he was working, one found the following:
>
> 2. You mentioned there are a couple of issues with the tests
> due to different character encodings. Is there a short
> sentence I could add to the README file like: "Note that
> some tests will fail on Genera because characters like...
> have encodings which differ from Perl's expectations?"
>
> Return, Linefeed, and Tab. There are others, such as Back-Space
> and Page, but I don't think they appeared in the tests.
>
> I think its unfortunate, for example, that this is the case. But
> <shrug> I still *love* having, for example, a regexp package with
> sexp notation for the regular expressions.
I agree with you that the desire to be compatible with Perl is
constraining CL-PPCRE a bit in edge cases but what you're citing above
is actually only about the CL-PPCRE /tests/ which are taken from the
PCRE (a C library) test suite. It does for example mean that
(scan "\\r" (string (code-char 13)))
will return a true result on the usual CL implementations on Unix,
Linux, Mac OS, or Windows while it'll return NIL on Genera. You'd have
the same problem if your CL code would assume that
(eql (char-code #\Return) 13)
is always true. (Imagine code which reads HTTP headers.)
Other than that, CL-PPCRE now works fine on Genera 8.5 thanks to the
efforts of Patrick O'Donnell.
Cheers,
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Damien Kick <······@email.mot.com> writes:
> I think its unfortunate, for example, that this is the case. But
> <shrug> I still *love* having, for example, a regexp package with sexp
> notation for the regular expressions.
You may find 'defpatt' utility for cl-ppcre useful, quoting from its
example section:
#| EXAMPLES
; If you want to try the examples, be sure to evaluate the
; expression below first - otherwise the other ones won't work.
; If you want to use a dispatching macro character, it must be
; defined separately.
> (defpatt:defpatt-set-default-macro-char)
; Note: Introduces #\� as a macro character
=> T
> (cl-ppcre:all-matches-as-strings �(alt "a" "c" "f") "abcdefghi")
; Note: Equivalent to "a|c|f"
=> ("a" "c" "f")
; That's all very well, but doesn't buy us very much.
; However `defpatt' (as per cl-ppcre's sexpr-based
; representation of REs) enables us to both document
; the patterns much better by letting us insert comments
; into REs...
> (cl-ppcre:scan-to-strings
�(seq digit+ ; used space
ws+
digit+ ; available space
ws+
digit+ ; remaining space
) "123 4567 7887")
; Note: `ws+' and `digit+' are defined above, in `defpatt-initialize'.
=> "123 4567 7887", #()
; ...as well as lets us capture data in a structured fashion...
> (cl-ppcre:register-groups-bind (used avail remain)
(�(seq (reg digit+) ; used space
ws+
(reg digit+) ; available space
ws+
(reg digit+) ; remaining space
) "123 4567 7887")
(mapcar #'parse-integer (list used avail remain)))
; Note: `(reg ...)' creates a register binding
=> (123 4567 7887)
; ...but also lets us _FIRST_ define and document the abstraction...
> (defpatt match-nums ()
(seq (reg digit+) ; used space
ws+
(reg digit+) ; available space
ws+
(reg digit+) ; remaining space
))
=> MATCH-NUMS
; ...and _THEN_ use it...
> (cl-ppcre:register-groups-bind (used avail remain)
(�match-nums "123 4567 7887")
(mapcar #'parse-integer (list used avail remain)))
=> (123 4567 7887)
; which is a lot more easily understood, as I am sure you will
; agree.
> (cl-ppcre:scan-to-strings �(upto "efg") "abcdefghi")
=> "abcd", #()
> (cl-ppcre:scan-to-strings �(upto+ "efg") "abcdefghi")
=> "abcdefg", #()
; To see the raw cl-ppcre expansion of a `defpatt' expression,
; simply enter it:
> �match-nums
=> (:SEQUENCE
(:REGISTER (:GREEDY-REPETITION 1 NIL (:CHAR-CLASS (:RANGE #\0 #\9))))
(:GREEDY-REPETITION 1 NIL :WHITESPACE-CHAR-CLASS)
(:REGISTER (:GREEDY-REPETITION 1 NIL (:CHAR-CLASS (:RANGE #\0 #\9))))
(:GREEDY-REPETITION 1 NIL :WHITESPACE-CHAR-CLASS)
(:REGISTER (:GREEDY-REPETITION 1 NIL (:CHAR-CLASS (:RANGE #\0 #\9)))))
; To see _HOW_ `defpatt' expands an expression use `macroexpand':
> (macroexpand-1 '�match-nums)
=> (SYMBOL-MACROLET ((MATCH-NUMS (#:G3523))
(WS (#:G3522))
(DIGIT (#:G3521))
(WS* (#:G3520))
(DIGIT* (#:G3519))
(WS+ (#:G3518))
(DIGIT+ (#:G3517)))
(LABELS ((GROUP (&REST DEFPATT::ARGS) `(:GROUP ,@DEFPATT::ARGS))
(SEQ (&REST DEFPATT::ARGS) `(:SEQUENCE ,@DEFPATT::ARGS))
(UPTO (DEFPATT::PATT)
`(:SEQUENCE
(:FLAGS :SINGLE-LINE-MODE-P)
(:GREEDY-REPETITION 0 NIL (:SEQUENCE :EVERYTHING (:NEGATIVE-LOOKAHEAD ,DEFPATT::PATT)))
:EVERYTHING))
(++ (DEFPATT::PATT) (REP DEFPATT::PATT 1 NIL))
(?? (DEFPATT::PATT) (REP DEFPATT::PATT 0 1))
(UPTO+ (DEFPATT::PATT) `(:SEQUENCE ,(UPTO DEFPATT::PATT) ,DEFPATT::PATT))
(ALT (&REST DEFPATT::ARGS) `(:ALTERNATION ,@DEFPATT::ARGS))
(** (DEFPATT::PATT) (REP DEFPATT::PATT 0 NIL))
(REG (&REST DEFPATT::ARGS) `(:REGISTER ,@DEFPATT::ARGS))
(RE (DEFPATT::PATT)
(PROGN
(UNLESS (STRINGP DEFPATT::PATT) (ERROR "Not a string: ~a." DEFPATT::PATT))
(DEFPATT::%PARSE-STRING DEFPATT::PATT)))
(REP (DEFPATT::PATT &OPTIONAL (MIN 0) (MAX NIL))
`(:GREEDY-REPETITION ,MIN ,MAX ,DEFPATT::PATT))
(#:G3523 () (SEQ (REG DIGIT+) WS+ (REG DIGIT+) WS+ (REG DIGIT+)))
(#:G3522 () :WHITESPACE-CHAR-CLASS)
(#:G3521 () '(:CHAR-CLASS (:RANGE #\0 #\9)))
(#:G3520 () (** WS))
(#:G3519 () (** DIGIT))
(#:G3518 () (++ WS))
(#:G3517 () (++ DIGIT)))
MATCH-NUMS))
; `upto' and `upto+' are good examples of how having an abstraction
; mechanism helps keep maintainable and understandable REs. See
; their definitions above.
|#
There's a link to defpatt on cl-ppcre's entry on www.cliki.net.
best,
-Klaus.
"Will Hartung" <·····@msoft.com> said:
>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.
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.
--
; Matthew Danish <·······@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 wrote:
> 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?
--
Cameron MacKinnon
Toronto, Canada
On Fri, May 07, 2004 at 09:44:37AM -0400, Cameron MacKinnon wrote:
> 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.
--
; Matthew Danish <·······@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 <··········@clearspot.net>:
> 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/
Matthew Danish wrote:
> 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.
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
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/
Pascal Costanza <········@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
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 <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
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 ······@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
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
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
On Sat, 08 May 2004 15:16:46 +0000, nikodemus wrote:
> Have you been in touch with any implementors -- commercial or otherwise?
I agree with doing so for the "otherwise". This is because the commercial
vendors (or their spokespeople) who post in this newsgroup seem to always
state that they have no resources to participate in this type of activity
(or that their resources would be much better spent elsewhere). Since they
have stated this numerous times before, what would be the point of asking
our poor cousins to burden themselves so grieviously?
No, I think that moving ahead and perhaps working on a community-centered
standard in conjunction with current open source implementations (who seem
to have less of a problem with resources) would be more worthwhile.
In other words, presenting the commercial implementors with an "evolve or
die" situation might be the only way forward.
faa
From: Friedrich Dominicus
Subject: Re: Modernizing Common Lisp
Date:
Message-ID: <871xluug1t.fsf@fbigm.here>
·········@random-state.net writes:
>
> 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!".
Well who cares under Perl on running regular expressions on anything
but strings? Reminds me on pathnames, with an API which is hardly to
understand and which forces you to be very carful with what you use in
your pathnames....
Friedrich
--
Please remove just-for-news- to reply via e-mail.
·········@random-state.net writes:
> 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!".
LOL!
I just busted a vain in my head trying to picture a Perl style regex
for a bit vector.
I think there is some .sig material there. You just need to fix the
run on senetence. "This really sucks! I can't use standard regexes
with bit vecotrs!"
How do you support foreign call backs? If you are calling C's sort
function (I know, I know), then you are giving it a C function pointer
that sort will be calling. sort is presumably in a standard C stack
frame from UFFI (I haven't looked at UFFI, so I am just speculating).
So sort will go ahead and push some arguments onto the stack and then
issue the call. If C calling is used, then the caller cleans up the
stack because C supports variable arguments. In Pascal style, the
callee has to clean up the stack. For sort, you know ahead of time
that you are doing C calling. Win32 has Pascal calling. Linux has
both C and fastcall. Why does this sound hairy to me?
I guess my real question is how do you deal with the multiple ABIs
that can exist in a single system?
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
> ·········@random-state.net writes:
>
> > 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!".
> How do you support foreign call backs? If you are calling C's sort
> function (I know, I know), then you are giving it a C function pointer
> that sort will be calling. sort is presumably in a standard C stack
> frame from UFFI (I haven't looked at UFFI, so I am just speculating).
> So sort will go ahead and push some arguments onto the stack and then
> issue the call. If C calling is used, then the caller cleans up the
> stack because C supports variable arguments. In Pascal style, the
> callee has to clean up the stack. For sort, you know ahead of time
> that you are doing C calling. Win32 has Pascal calling. Linux has
> both C and fastcall. Why does this sound hairy to me?
>
You have it somehow backwards. Linux uses C (caller-cleans), while
Windows has both conventions C, and Pascal (callee-cleans)
I don't think the ABI should be a problem for supporting callbacks.
David Steuber <·····@david-steuber.com> writes:
> How do you support foreign call backs? If you are calling C's sort
> function (I know, I know), then you are giving it a C function pointer
> that sort will be calling. sort is presumably in a standard C stack
> frame from UFFI (I haven't looked at UFFI, so I am just speculating).
> So sort will go ahead and push some arguments onto the stack and then
> issue the call. If C calling is used, then the caller cleans up the
> stack because C supports variable arguments. In Pascal style, the
> callee has to clean up the stack. For sort, you know ahead of time
> that you are doing C calling. Win32 has Pascal calling. Linux has
> both C and fastcall. Why does this sound hairy to me?
>
> I guess my real question is how do you deal with the multiple ABIs
> that can exist in a single system?
You match the calls with the ABIs. See
http://www.franz.com/support/documentation/6.2/doc/pages/operators/ff/defun-foreign-callable.htm
and especially note the :convention option, which especially can be
:c or :stdcall (i.e. pascal-style).
--
Duane Rettig ·····@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
David Steuber <·····@david-steuber.com> wrote:
+---------------
| How do you support foreign call backs?
+---------------
It depends rather much upon the particular Lisp implementation.
For example, see the following URL for what CMUCL supplies in
its "alien" FFI facility:
<URL:ftp://ftp.linux.org.uk/pub/lisp/cmucl/doc/cmu-user/aliens.html#toc251>
8.7.4 Calling Lisp from C
Calling Lisp functions from C is sometimes possible, but is rather hackish.
...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
>>>>> "rw" == Rob Warnock <····@rpw3.org> writes:
rw> For example, see the following URL for what CMUCL supplies in
rw> its "alien" FFI facility:
rw>
rw> <URL:ftp://ftp.linux.org.uk/pub/lisp/cmucl/doc/cmu-user/aliens.html#toc251>
rw> 8.7.4 Calling Lisp from C
rw>
rw> Calling Lisp functions from C is sometimes possible, but is rather hackish.
the 19a release of CMUCL (due soon now) will provide a more
convenient way of calling Lisp from C, contributed by Helmut Eller. It
consists of creating a "trampoline", or segment of machine code that
is responsible for copying the arguments from the C stack into
CMUCL's format, finding the address of the lisp function and calling
it.
This mechanism is available in the monthly snapshot binaries if
people want to try them out (we need testers!). The interface is
described in the development version of the CMUCL documentation.
<URL:ftp://ftp.common-lisp.net/pub/project/cmucl/doc/devel/html/aliens.html#toc265>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> So for example someone mentioned standardizing on Franz's FFI
> interface. This is probably a good idea, [...]
This would be a very bad idea.
Any API that exhibits too much of its internals is a nightmare for
every other implementor. As an example, IIRC, Franz zero-terminates
its Lisp strings and allows foreign (e.g. C) functions to receive
pointers to Lisp strings, which works because of the 0 termination.
I bet no implementor of a Lisp whose strings are not zero-terminated
will want to implement that change. They had their very good reasons
not to do so back when they initially designed the layout of the Lisp
string object.
As an aside, I already expressed in the UFFI mailing list (last year
or so) why the current UFFI is not a good candidate for
standardization. The key critique is that it lacks declarative power.
CMUCL and CLISP's FFI are examples of very declarative FFI, which IMHO
are the only ones for which I'd conceive standardization. They
describe properties like input or output parameters, saying "what"
instead of "the low-level stepts of how" to interface.
I wouldn't wish standardization of some crufty Perl/Python like e.g.
"dsdcl" description string which describes how to pass parameters
(here a fouble float, a C string, another double, a character and a
long). No Common Lisp I know has such an interface, but Perl and
Pythonites seem happy with that.
The advantage of the declaratiev approach is that the implementors can
figure out how to implement the high-level FFI declaration using the
low-level FFI constructs.
It would be much harder, as the example shows, to map a low-level API
to another low-level API.
I believe CLOS and many other parts of CL are examples which show how
high-level APIs win big.
Regards,
Jorg Hohle
Telekom/T-Systems Service Center Security
In article <······················@speakeasy.net>,
····@rpw3.org (Rob Warnock) writes:
> Pascal Costanza <········@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
Pascal Costanza wrote:
> You are making this up and describe in exaggerated terms what you
> probably haven't even experienced yet yourself. Am I right?
I'm a Lisp newbie, so I admit I have not experienced it in Lisp. But I have
been programming on many systems for 25 years. I have experienced exactly
these sorts of problems with many other languages, systems, etc., for a
long time. Thus, while you may think me unqualified because of my Lisp
newbie status, I don't think my opinions are ill formed. They have been
shaped by decades of experience in such areas.
> 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.
Folks, I don't want this to seem like a "the sky is falling" sort of
discussion here. I don't think that any reasonable person on either side
would say that the world will end, CL will die, or anything else if these
problems are not solved. CL has survived without these things for a long
time. I'm sure that even if these questions are not dealt with, it will
survive for many more.
But the question I'm asking is, don't people think that the friction of
compatibility slows things down and saps cycles that would otherwise be
spend on more valuable endeavors? Don't you think that various incompatible
versions of the same thing creates friction that retards the network
effect? If you don't, then I guess we just disagree. That's fine. Lets get
over it and move on. ;-)
But let me try to explain this again. I'm going to use Unix as an example.
For 15 years, we had fragmented Unix variants. Now, the world has finally
decided that Linux is going to be the default. And look at how that helps
move the system forward. Whereas you used to have one application written
for Solaris that couldn't be used on HP-UX or IRIX or vice-versa, you now
have everybody writing to Linux as the common API and suddenly you have
everybody announcing a Linux strategy.
We all used to run different networking protocols: TCP/IP, DECnet, IPX,
Appletalk. Again 100 different ways of doing the same thing: moving packets
around. It created great armies of people building multi-protocol routers.
Finally, the world decided that TCP/IP and Ethernet were THE WAY to do
networking. Suddenly, the Internet takes off, we have global connectivity,
global email, and the old protocols are dead.
And we could go on, and on, and on: ASCII, serial ports, SCSI, etc.
In other words, the network effect at work.
> 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.
Okay, I would agree with that. The question is, how much should you have to
worry about in terms of the port? Again, I'm not arguing for a utopian,
perfect world where all code just comes up, compiles and runs without a
thought. That won't happen. Ever. You'll always have hiccups here and
there. The question is, what level of expectation should we have? Should we
expect the hiccups to be the exception or the rule? Again, I'll go back to
the old argument: the world standardized on CAR, CDR, MAPCAR, and LIST. I
think that everybody agrees that was good, otherwise we'd all have our own
custom Lisps and moving code would always be a *massive* porting job (a
rewrite, basically). That's obviously bad. So why stop at CAR, CDR, MAPCAR,
and LIST? If there are other APIs that are near as universal, why don't we
spec those too, and take them off the table (barring the odd exception, as
I said)? It's just a matter of degree. I don't think anybody is arguing
that we should standardize *everything* that can be standardized. But I
think that the bar has been raised way beyond where it was in the late
1980s in terms of what is now commonplace in our world. Things like threads
and networking are just part of computers now. Unicode is the new ASCII. So
why not evolve our programming languages to take these advances into
account so we can reap the benefits as a collective?
> 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.)
Yup, that tracks my experience, too. Again, the world ain't perfect. The
question is, do you try or do you roll over and let entropy take its
course?
> The apparently widely held belief that you only need to standardize
> stuff in order to get portable / reusable code is a pretty bad idea.
Agreed. I don't hold that belief. But it's the starting point. Without that
foundation, you have no hope. Also, let me be specific that "standard" in
my mind does not necessarily equate to ANSI, et. al. In my mind, it seems
like ASDF is working itself up to be quite a defacto standard here in the
CL world. That's perfect. No need for ANSI with its politics and its bloat.
> 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.
I think that those are largely examples where people have tried to
standardize things that weren't ready to be standardized. Again, I am
certainly not advocating trying to standardize all manner of API. And I
would say that even when you have a standard, there are sometimes good
reasons for going with the non-standard solution. A standard just means
that something is by default available as an option. It doesn't mean that
everybody has to use it in every situation. But it tips the scales such
that most people will just use it and not think about it. In other words,
the game shifts to "Unless you have a good reason to avoid doing things
like this, do it like this..."
> 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.
Agreed. I have worked on standards in the networking industry for years. The
best standards are the ones where people largely already agree and you're
just codifying the existing practice (even then you'll run into all sorts
of political problems, but it's a start). When you are coming into a room
to try to drive new solutions to new problems, you'll probably botch it up
and it will take you until Rev 3 to fix it. By that time everybody will
have enough implementation and deployment experience to know what works.
> 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.
Agreed, but let's talk specifics. Would you disagree that we could probably
standardize on a BSD sockets-like interface for networking? If so, then
let's just lay down what the actual function names and parameters are and
be done with it. How many thread APIs are there? Let's just pick one and
move on.
> 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.
"Pick one [character set encoding, Unix variant, networking protocol stack,
etc.] that best suits your needs..." Yes, at some level, I will certainly
do that. But if we aren't careful, that's just a recipie for balkanization.
I guess I think that there are probably things that have reached the stage
of being so obvious that you could do them now.
> 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.
Cool. I agree with that. Let's do this on CLiki. It doesn't have to be a big
ANSI process. Some of the best "specs" I have participated in started out
as a whitepaper or informal spec. The important thing is to write it down.
> 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.
I don't want anybody to think that I ever said "official standards process."
I hate those. I agree with you: they are too expensive and full of all the
wrong motives.
> 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.
Whoa! Perhaps I miscommunicated here. My original posting wasn't meant to:
1. Create pressure
2. Get anybody to listen
3. Influence any direction
4. Gain influence myself without investing in something
I simply found something while Googling, thought it was interesting, posted
it, and asked for comments. Previously, I had found myself wondering if
anybody had thought about standardizing some of these things as these
seemed like enhancements that are very natural to me. The paper I posted a
link to resonated with my sense of there being a hole in these areas.
That said, it seems I have struck a big nerve with you and others. I'm not
sure what that is, but I'll back off now.
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Dave Roberts wrote:
> Pascal Costanza wrote:
>
>>You are making this up and describe in exaggerated terms what you
>>probably haven't even experienced yet yourself. Am I right?
>
> I'm a Lisp newbie, so I admit I have not experienced it in Lisp. But I have
> been programming on many systems for 25 years. I have experienced exactly
> these sorts of problems with many other languages, systems, etc., for a
> long time. Thus, while you may think me unqualified because of my Lisp
> newbie status, I don't think my opinions are ill formed. They have been
> shaped by decades of experience in such areas.
It's important that we are talking about Lisp here. Lisp is so flexible
that the problems you have described in your previous post, while they
still occur, aren't that severe as in other languages. It is much easier
to code around limitations and bugs. At least in my experience, and this
is also what I also hear from others.
> CL has survived without these things for a long
> time. I'm sure that even if these questions are not dealt with, it will
> survive for many more.
>
> But the question I'm asking is, don't people think that the friction of
> compatibility slows things down and saps cycles that would otherwise be
> spend on more valuable endeavors?
Because of my interests, I have mainly been playing around with CLOS and
the MOP. On some occasions, I have stumbled across bugs in CL
implementations, or at least what I have perceived as bugs, in the
object system itself. The cool thing is that I was almost always able to
quickly fix them myself. These were bugs of the caliber that would mean
serious delays in other languages, because compilers would need to be
changed, maybe even object models would need to be fixed, and so on. As
an extreme case, take a look at how many years Java has taken to
integrate generic types.
So no, I don't think that software development is seriously slowed down
because of incompatibilities in libraries. I rather think that because
software development with Lisp is so fast, the need for more
standardization isn't nearly as high as elsewhere.
> "Pick one [character set encoding, Unix variant, networking protocol stack,
> etc.] that best suits your needs..." Yes, at some level, I will certainly
> do that. But if we aren't careful, that's just a recipie for balkanization.
I don't think so.
> That said, it seems I have struck a big nerve with you and others. I'm not
> sure what that is, but I'll back off now.
Probably a question of terminology. The Lisp world has achieved high
quality standards with ANSI CL and the various revisions of Scheme
reports. When you use the word "standard", you have to expect that
people will think of those when they hear it. It seems to me by now that
you mean something much more pragmatic.
What I hear from other people, the Common Lisp community has had its
darkest time about five years ago. It has only been since recently that
new people start to discover it, and that the community is growing
again. (Someone please correct if I am wrong.)
I guess that there will be quite a number of useful de-facto-standard
libraries in about one or two years the latest. In the meantime you can
choose either to be part of it, or to join again when things got better.
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/
Pascal Costanza wrote:
> It's important that we are talking about Lisp here. Lisp is so flexible
> that the problems you have described in your previous post, while they
> still occur, aren't that severe as in other languages. It is much easier
> to code around limitations and bugs. At least in my experience, and this
> is also what I also hear from others.
Hmm... I don't think so. That is, my fundamental issue isn't that we can't
use Lisp to build everything we want to build. Quite the contrary. While
Lisp certainly is flexible (and indeed your Highly Opinionated Guide to
Lisp was one of the resources that got me very interested in it as a
language), the question is whether we should have to build all this stuff
all ourselves. That is, I have no doubt that everybody can use Lisp's great
flexibility to go around and hack up their own compatibility layer for
things like sockets (threads are a bit more difficult if you want to do it
right since they interact with things like GC that are deep in the
runtime), but should we? Is that a good use of our time?
> Because of my interests, I have mainly been playing around with CLOS and
> the MOP. On some occasions, I have stumbled across bugs in CL
> implementations, or at least what I have perceived as bugs, in the
> object system itself. The cool thing is that I was almost always able to
> quickly fix them myself. These were bugs of the caliber that would mean
> serious delays in other languages, because compilers would need to be
> changed, maybe even object models would need to be fixed, and so on. As
> an extreme case, take a look at how many years Java has taken to
> integrate generic types.
Hmmm... but I'm not sure what you point is. Yes, CLOS and the MOP are very
flexible. The great thing about at least CLOS is that it's also
standardized such that you can write an object and I can write an object
using the same system and they pretty much can work together. The MOP is
not standardized though it sounds (have to verify) that a lot of
implementaitons use AMOP as a basis.
Actually, CLOS is a great example of just what I'm talking about. Using the
great flexibility of CLOS, we all could have developed our own object
systems. Thank goodness they developed CLOS, however, such that we don't
have to.
> So no, I don't think that software development is seriously slowed down
> because of incompatibilities in libraries. I rather think that because
> software development with Lisp is so fast, the need for more
> standardization isn't nearly as high as elsewhere.
Then I guess I disagree here. Yes, Lisp is faster for development, but
porting anything is still a non-zero-time activity, even in a flexible,
productive language. The more we reduce this for the obvious stuff that
everybody uses, the better off we all are.
>> "Pick one [character set encoding, Unix variant, networking protocol
>> stack, etc.] that best suits your needs..." Yes, at some level, I will
>> certainly do that. But if we aren't careful, that's just a recipie for
>> balkanization.
>
> I don't think so.
Hmmm... what was the state of Lisp before CL? Wasn't it non-standard and
balkanized? Didn't the development of CL reduce that balkanization for the
basic functions? Maybe I'm wrong, but my impression from reading all the
literature is that CL really helped to consolidate the fractured market.
All I'm saying is to repeat sort of the same process (again, maybe without
the ANSI backing) on functionality at a different level (sockets, threads,
unicode, etc. vs. CAR/CDR/MAPCAR/LIST).
>> That said, it seems I have struck a big nerve with you and others. I'm
>> not sure what that is, but I'll back off now.
>
> Probably a question of terminology. The Lisp world has achieved high
> quality standards with ANSI CL and the various revisions of Scheme
> reports. When you use the word "standard", you have to expect that
> people will think of those when they hear it. It seems to me by now that
> you mean something much more pragmatic.
Fair enough. I'm much more pragmatic. I always liked the old IETF
description of "rough consensus and running code."
> What I hear from other people, the Common Lisp community has had its
> darkest time about five years ago. It has only been since recently that
> new people start to discover it, and that the community is growing
> again. (Someone please correct if I am wrong.)
Seems like it. I'm here. ;-)
> I guess that there will be quite a number of useful de-facto-standard
> libraries in about one or two years the latest. In the meantime you can
> choose either to be part of it, or to join again when things got better.
Again, my interest in CL started before I examined these issues. They aren't
fatal, IMHO, just very non-optimal. In short, whether anybody agrees with
me that these are holes that need filling, I'm still interested in learning
and participating. At some point, I'll transition from newbie status to
something better and perhaps I can start contributing some solutions at
that point rather than just asking difficult, pointed questions... ;-)
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Dave Roberts wrote:
> Pascal Costanza wrote:
>
>
>>It's important that we are talking about Lisp here. Lisp is so flexible
>>that the problems you have described in your previous post, while they
>>still occur, aren't that severe as in other languages. It is much easier
>>to code around limitations and bugs. At least in my experience, and this
>>is also what I also hear from others.
>
>
> Hmm... I don't think so. That is, my fundamental issue isn't that we can't
> use Lisp to build everything we want to build. Quite the contrary. While
> Lisp certainly is flexible (and indeed your Highly Opinionated Guide to
> Lisp was one of the resources that got me very interested in it as a
> language), the question is whether we should have to build all this stuff
> all ourselves. That is, I have no doubt that everybody can use Lisp's great
> flexibility to go around and hack up their own compatibility layer for
> things like sockets (threads are a bit more difficult if you want to do it
> right since they interact with things like GC that are deep in the
> runtime), but should we? Is that a good use of our time?
My, my, this thread has dragged on a long time. We could all be
discussing Cello! What everyone has failed to point out is that we have
a "non-existence proof" in hand to refute your argument that Lispniks
should drop everything and get to work on your "standardization"
obsession: those of us (unlike you) actually using Lisp to do stuff are
simply not interested in all this crap about standardizing x, y, and z.
it would be lovely if they /were/ standardized, but look! no one is
bothering about it. aka, the non-existence proof. now how can this be?
how can it be both better to be standardized and a big fucking yawn to
real Lispniks? puzzlepuzzlepuzzle... well, you are not a lispnik yet
because you are not actually using it, you are just a usenet junkie
yapping away no matter how often real lispniks tell you "yawn", so the
puzzle cannot be explained to you. but once you get off usenet and write
some code you will discover that Lisp basically slams you back into your
desk chair with about 10g's of acceleration, at which point you will get
so fucking excited about programming some /application/ that you won't
much care if it is portable to some other Lisp, and even if you do, that
the differences can be hidden in a macro or two and away you go.
now to expedite things, as a community service, here is what you should
write in reponse to this article: Lisp.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> those of us (unlike you) actually using Lisp to do stuff are simply
> not interested in all this crap about standardizing x, y, and z. it
> would be lovely if they /were/ standardized, but look! no one is
> bothering about it. aka, the non-existence proof.
People actually using C++ to do stuff are simply not interested in all
this crap about structured uniform syntax, powerful macros, having a
programmable language, incremental development style, a condition
system that handles conditions rather than merely containing errors,
etc. etc. etc. etc. ... no one is bothering about it. aka, the
non-existince proof.
[Warning to the parody-impaired: the above is NOT a direct
representation of my views but an illustration of why I find Kenny's
presentation of his argument less than convincing.]
You're presenting Paul Graham's Blub-user argument, albeit in a
slightly different direction: I'm happy with my tools because they are
what I have got used to; I've got used to the suffering my tools
inflict on me to the extent that I don't really notice the pain any
more.
Just because you have been numbed to that particular pain, doesn't
mean that others are not justifiably moved to consider how the status
quo might be improved.
If you are bored by people talking about improving the world in this
particular way, then don't read the sodding thread ... more
importantly, don't contribute to it.
Jacek Generowicz wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>those of us (unlike you) actually using Lisp to do stuff are simply
>>not interested in all this crap about standardizing x, y, and z. it
>>would be lovely if they /were/ standardized, but look! no one is
>>bothering about it. aka, the non-existence proof.
>
...
>
> You're presenting Paul Graham's Blub-user argument, albeit in a
> slightly different direction: I'm happy with my tools because they are
> what I have got used to; I've got used to the suffering my tools
> inflict on me to the extent that I don't really notice the pain any
> more.
>
> Just because you have been numbed to that particular pain, doesn't
> mean that others are not justifiably moved to consider how the status
> quo might be improved.
>
So your thesis is that Lispniks are not sensitive to productivity
issues, or can be numbed to it? The latter is as unlikely as is the
former preposterous: aggravations only become more irritating the more
often one encounters them. That comes from someone who just ported Cello
from AllegroCL to Lispworks for the fourth or fifth time.
Don't get me wrong. I said originally it would be lovely if the Library
Standards Fairy would leave CL-FFI and CL-SOCKETS under our pillows
tonight. Can't wait till morning!
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Jacek Generowicz wrote:
>
> > Just because you have been numbed to that particular pain, doesn't
> > mean that others are not justifiably moved to consider how the status
> > quo might be improved.
>
> So your thesis is that Lispniks are not sensitive to productivity
> issues, or can be numbed to it? The latter is as unlikely as is the
> former preposterous: aggravations only become more irritating the more
> often one encounters them. That comes from someone who just ported Cello
> from AllegroCL to Lispworks for the fourth or fifth time.
The problem with the melodramatic arguments for standardized FFI,
networking, etc., is that they're overdone. The thing is, it really
*isn't* very hard to port networking code. I have a web application
framework that lets me deploy with CLISP as a set of cgi scripts; cgi
is hell as a development environment, so it also runs as a server
under CMUCL and SBCL (when I want the good compiler diagnostics), and
MCL (when I want the best environment I can get on my Mac).
It took about 30-40 minutes of cussing and complaining about the State
of Lisp, but after that, and some testing, I had a networking layer
that worked on Lisps with Unix-like networking (everything but MCL),
and with OpenTransport (MCL). And everything else Just Worked. Much
to my delight, even pathnames. Too much time in the C++ world left me
with a distinct taste of "L'Enfer, c'est les autres" when it comes to
libraries; otherwise, or if I'd thought it would be hard, I would have
just gotten one of the existing compatability libraries. And this is
the worst-case scenario (MCL). Unix/Windows Lisps are easy.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> The problem with the melodramatic arguments for standardized FFI,
> networking, etc., is that they're overdone. The thing is, it really
> *isn't* very hard to port networking code.
...
> It took about 30-40 minutes of cussing and complaining about the State
> of Lisp, but after that, and some testing, I had a networking layer
> that worked...
I don't think anyone here is arguing against this. In fact, I've seen it
argued that the REASON for the umpteen compatibility layers kicking
around is that Lisp makes it so easy to roll your own, and I would tend
to agree.
Easy or not, it's hard to twist the necessity of fiddling around for
compatibility into a virtue. I'm not going to reiterate the reasons that
some of us have for believing that making some of this fiddling
redundant would be a good thing, they've all been covered quite well in
this thread.
It appears that there's a group of us achieving critical mass here,
willing to work on some of these issues. We're not trying to press-gang
everyone else into working on them, and we're not just throwing rocks at
the current language for sport, our detractors' accusations
notwithstanding.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> It appears that there's a group of us achieving critical mass here,
> willing to work on some of these issues. We're not trying to press-gang
It appears to me (and admittedly I've only scanned this thread on
google groups, as I don't usually read cll any more) to be more like
the usual "we're going to whine about lack of standards (or lack of
process to define a standard) as a substitute for doing any work on
these issues". If this is not your intention and you think you're
getting an unnecessarily hard time, know only that this thread comes
around annually and has never yet produced a step change in the
quality, number, or availability of common lisp {sub,pseudo,layered,de
facto}-standards; your detractors are probably waiting to see if your
words are actually backed by actions. If so, you may take a certain
pride in being the first.
-dan
If you look a bit more closely you will see that many of us are doing
something about it.
Furhermode a lot has already been done.
Take CC-PPCRE, ADSL, UFFI and McCLIM.
As for new efforts there is Cello.
Personally I am working on a fastCGI interface..
On 11 May 2004 02:37:27 -0700, Daniel Barlow <···@telent.net> wrote:
> Cameron MacKinnon <··········@clearspot.net> wrote in message
> news:<······················@golden.net>...
>> It appears that there's a group of us achieving critical mass here,
>> willing to work on some of these issues. We're not trying to press-gang
>
> It appears to me (and admittedly I've only scanned this thread on
> google groups, as I don't usually read cll any more) to be more like
> the usual "we're going to whine about lack of standards (or lack of
> process to define a standard) as a substitute for doing any work on
> these issues". If this is not your intention and you think you're
> getting an unnecessarily hard time, know only that this thread comes
> around annually and has never yet produced a step change in the
> quality, number, or availability of common lisp {sub,pseudo,layered,de
> facto}-standards; your detractors are probably waiting to see if your
> words are actually backed by actions. If so, you may take a certain
> pride in being the first.
>
>
>
> -dan
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> If you look a bit more closely you will see that many of us are doing
> something about it.
Who is this "us"?
> Furhermode a lot has already been done.
> Take CC-PPCRE
I assume you mean CL-PPCRE. That was largely the work of Edi Weitz.
> ADSL
Here I'm guessing you mean ASDF. _I_ wrote that.
> UFFI
Kevin Rosenberg
> and McCLIM.
Tim Moore, Robert Strandh, Mike McDonald, Andy Hefner, Mikel Evins and
no doubt others I can't remember off the top of my head. You could
also have mentioned CLX, on which this work depends
My question to you: how many of the above-named (or the other
contributors to said software whose names I've omitted, and to whome I
apologise for so doing) have posted articles in this thread pushing
for the creation of de-facto standards?
Show us the code!
-dan
--
"please make sure that the person is your friend before you confirm"
Sorry if by us you assumed that I haved been involved in all these efforts.
By us I meant comp.lang.lisp.
If per chance you want some look at my code I have written look at
http://home.chello.no/~jthing
for some games.
On Tue, 11 May 2004 12:24:07 +0100, Daniel Barlow <···@telent.net> wrote:
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad <··············@chello.no> wrote:
> Sorry if by us you assumed that I haved been involved in all these efforts.
> By us I meant comp.lang.lisp.
Oh, I see. Comp.lang.lisp produces code these days. How strange that I
always thought that individuals --like Dan for example-- did that, and the
fact that they also occasionally post on cll was just incidental.
I see now how they would never have done any of this if it were not for
cll, and how valuable and insightful advice from cll has had a deep
impact on the quality of their work.
Thanks for setting us straight,
-- Nikod^Wcomp.lang.lisp ,)
Spare me your irony.
I have benefited a great deal from contribution and announceents through
this newsgroup.
By refering to "us" I assume that there is (such a thing as) a lisp
community.
Some of "us" even meet (in person).
I "assume/think" you belive every lisp programmer is like an island and
only joins
c.l.l like once a year to brag.
Well it ain't so.
John
On 11 May 2004 13:47:09 GMT, <·········@random-state.net> wrote:
> John Thingstad <··············@chello.no> wrote:
>
>> Sorry if by us you assumed that I haved been involved in all these
>> efforts.
>> By us I meant comp.lang.lisp.
>
> Oh, I see. Comp.lang.lisp produces code these days. How strange that I
> always thought that individuals --like Dan for example-- did that, and
> the
> fact that they also occasionally post on cll was just incidental.
>
> I see now how they would never have done any of this if it were not for
> cll, and how valuable and insightful advice from cll has had a deep
> impact on the quality of their work.
>
> Thanks for setting us straight,
>
> -- Nikod^Wcomp.lang.lisp ,)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad <··············@chello.no> wrote:
+---------------
| Daniel Barlow <···@telent.net> wrote:
| > It appears to me ... to be more like the usual "we're going to whine
| > about lack of standards (or lack of process to define a standard) as
| > a substitute for doing any work on issues".
|
| If you look a bit more closely you will see that many of us are doing
| something about it. Furhermode a lot has already been done.
| Take CC-PPCRE, ADSL, UFFI and McCLIM.
+---------------
Uh... If you look a bit more closely you might discover who *wrote* ASDF...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"John Thingstad" <··············@chello.no> writes:
> Personally I am working on a fastCGI interface..
Are you aware of
o the fastCGI module for CLISP, by John K. Hinsdale?
o the fastCGI implementation for CMUCL by Teemu Kalvas?
See http://www.cliki.net/FastCGI
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Yes
1. CLISP is a interface to the C library. Mine is a all lisp interface.
2. I am using Corman Lisp.
It simply seemed simpler to roll my own.
John
On 14 May 2004 14:27:14 +0200, Joerg Hoehle <······@users.sourceforge.net>
wrote:
> "John Thingstad" <··············@chello.no> writes:
>> Personally I am working on a fastCGI interface..
> Are you aware of
> o the fastCGI module for CLISP, by John K. Hinsdale?
> o the fastCGI implementation for CMUCL by Teemu Kalvas?
> See http://www.cliki.net/FastCGI
>
> Regards,
> Jorg Hohle
> Telekom/T-Systems Technology Center
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
In article <····························@posting.google.com>,
Daniel Barlow <···@telent.net> wrote:
>It appears to me (and admittedly I've only scanned this thread on
>google groups, as I don't usually read cll any more) to be more like
>the usual "we're going to whine about lack of standards (or lack of
>process to define a standard) as a substitute for doing any work on
>these issues".
It's not a substitute. Someone like me, who's trying out CL to see if
it's worth getting deeply involved in, is in no position to do
anything much toward getting CL's shit together. The people
who can do that are those who have made significant contributions,
have significant experience, and would command significant respect in
the CL world.
I'm just reading along, making the occasional post out of a frustrated
sense that people are missing the point, and trying to figure out if
there's even any desire on anyone's part to improve the situation; and
I've been a bit dispirited when, for instance, reading the responses
to Peter Seibel's eminently sensible and dead-on posts...
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski <···@klio.org> writes:
> I'm just reading along, making the occasional post out of a frustrated
> sense that people are missing the point, and trying to figure out if
> there's even any desire on anyone's part to improve the situation; and
Well, there used to be. I used to care about new users: I wrote a
document unofficially entitled the CMUCL-HOWTO describing how to
install a reasonable lisp development environment on a Linux box.
This was in around 1999/2000, so it covered the use of tools like
mk-defsystem, where to find ilisp (some ftp site whose name I can't
even remember), hyperspec.el (at that time not part of ilisp), and so
on.
Being somewhat dissatisfied with the general state of polishedness,
amount of manual configuration, etc, that seemed to be involved with
this, I created cliki and the tools and libraries it relies on, and
was instrumental in the creation of cclan - both attempts to collect
all the bits together; I hacked significantly on SBCL - a CMUCL
variant with the goal of being rebuildable by mortal man; I wrote asdf
as a cleaner and more extensible replacement for mk-defsystem, then
asdf-install to help with the dependency mess. Bits of the SLIME (a
cleaner nicer ILISP replacement) code have my name on them too. I've
also been keeping an FTP mirror of the CMUCL distribution, and a CVS
tree for a CLX branch which as far as I know has more bug fixes and
extensions than any version of CLX shipped by any other vendor.
I don't especially wish to blow my own trumpet here; I'm hardly the
only person to have invested a fairly significant amount of time
improving the CL libraries/infrastructure situation, at least insofar
as it relates to free lisp software. You only have to read the
READMEs in any of the packages you download these days to see the same
names cropping up again and again. Look at allegroserve and its
portable variant, openmcl, cl-ppcre, xmls, common-lisp.net, clsql and
related projects, cl-pdf/cl-typesetting, mcclim and the apps under
development for it, ucw, and a pile of other stuff. Any of this that
even existed five years ago (very little of it) was looking
considerably more bare.
So I say "used to care", and you're wondering what changed. Simply, I
realised that no matter how much time, effort, work or money is
plunged into free software (in fairness, this is unlikely to be unique
to Lisp) the response from this "new user" market is always going to
be "Sucks. Is there even any desire on anyone's part to improve the
situation?". Anything you did more than three weeks ago when they
started looking at lisp is taken for granted, assumed to be provided
by some capricious god in Days of Old and now just part of the natural
state of things.
So, no, as far as I'm concerned, there isn't any such desire. These
days I write code because (and when) I enjoy it and I think it'll be
useful to me or to my fellow hackers; if I decide I'd enjoy something
else more, I'll do that instead. The new users can go and fuck
themselves. Or they can attempt to set up their Lisp systems using
only tools and libraries that were available in 1998 and see how they
get on. Good luck guys; I hear that CMUCL has just gained an x86
backend, so you might be able to get it running on Linux. You may
need to crosscompile from Alpha, though.
-dan
--
"please make sure that the person is your friend before you confirm"
On Tue, 11 May 2004 15:33:36 +0100, Daniel Barlow wrote:
> I used to care about new users...
One thing that I want to make clear about my position - I'm not sure if
I really care much about "new users" either. I am still trying to sort
out the pro's and con's about working in what I've come to think of as a
"boutique technology" (anyone who wants clarification on that term
can talk to me privately). If I finally come to the point where I
think that the con's of working with such a technology outweigh the pro's,
my position on new users might change. Until that point comes, though, my
position is based primarily on selfishness. I want these things
standardized because it would make life easier for me. That I think it
would make things easier for others in the community is simply an added
benefit.
Why the clarification? Because I think that there may be misconceptions
in the community that all of us who want these features standardized want
it because they want the audience for the language to grow. I believe
that there are many out there (like me) who simply want these things
included to make life easier for themselves when they write code that they
might someday wish to port to other implementations (which, at least to
me, is as good a reason as any to want this). I would hope that those who
believe that standardization is bad because it panders to new users would
consider that there may be a wider range of motives behind the desire.
faa
In article <··············@noetbook.telent.net>,
Daniel Barlow <···@telent.net> wrote:
>Being somewhat dissatisfied with the general state of polishedness,
>amount of manual configuration, etc, that seemed to be involved with
>this, I [did a whole bunch o' stuff]
All of which is very useful and well-done, to be sure, and large
improvements on what existed before. Thanks.
My intent in airing my frustration is not to disparage the real and
valuable work that people have done. I doubt I'd still be looking at
CL at all, if it weren't for the work you, and people like you, have
done. (Ironically, work that makes Lisp significantly better may even
increase the volume of complaints because fewer people just shrug
dismissively and move on.)
>realised that no matter how much time, effort, work or money is
>plunged into free software (in fairness, this is unlikely to be unique
>to Lisp) the response from this "new user" market is always going to
>be "Sucks. Is there even any desire on anyone's part to improve the
>situation?".
Not only is it not unique to Lisp, it's not unique to free software.
Yeah, Linux gets people looking at it and saying, "So when are you
guys going to have a desktop that I could actually use?" despite
thousands of hours of intense work; but Microsoft gets people bitching
about how much XP sucks and wondering when they'll make a good OS,
too. (And for that matter, the people who use the corporate apps I
deliver bitch about them whenever there's a problem, too.)
Users are selfish little pricks, who only seem to care about what they
can't do, and take for granted what they can. The only difference
between open-source and commercial work, in this respect, is that
there's more incentive to work through the bitching when the work is
paying your mortgage...
--
Mike Kozlowski
http://www.klio.org/mlk/
Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> So I say "used to care", and you're wondering what changed. Simply, I
> realised that no matter how much time, effort, work or money is
> plunged into free software (in fairness, this is unlikely to be unique
> to Lisp) the response from this "new user" market is always going to
> be "Sucks. Is there even any desire on anyone's part to improve the
> situation?". Anything you did more than three weeks ago when they
> started looking at lisp is taken for granted, assumed to be provided
> by some capricious god in Days of Old and now just part of the natural
> state of things.
>
> So, no, as far as I'm concerned, there isn't any such desire. These
> days I write code because (and when) I enjoy it and I think it'll be
> useful to me or to my fellow hackers; if I decide I'd enjoy something
> else more, I'll do that instead. The new users can go and fuck
> themselves. Or they can attempt to set up their Lisp systems using
> only tools and libraries that were available in 1998 and see how they
> get on.
The social problems you describe actually account for many problems
"modern" countries have which strech back centuries. And marketing
departments have trained programmers to expect and demand Features
from other Products; people are lied to and told they need to jump
onto The Next New Thing or they'll be unemployed tomorrow. So there's
a resentment at work. Especially since there are people who say,
"You're an idiot if you don't know lisp!" I think these account for
the complainers you perceive.
As for someone who's still rewriting that psychological programming,
there are a number of other issues that aren't obvious. For example,
I've been easily able to learn languages intuitively; just sort of
grok the gist and we're ready to go. Never respected programming, and
thought programmers led dull, slow lives where learning new things was
just about being boring enough to care. However with lisp I've had to
confront certain holes where I was incompetent. Even recently, I've
tended to blame lisp or someone's writing ability when my intuition
was not enough to compensate for skimming over everything.
Fortunately I seem to process things "out loud," so I have a good
online record of this...
So anyway, if you don't like writing that software, good for you. Just
mentioning something you might've not noticed.
> (in fairness, this is unlikely to be unique to Lisp)
Don't be so sure. One result of this newsgroup's previous abusiveness
was an enormous amount of schadenfreude directed at lispers' efforts.
As an American I know what I'm talking about here.. <shrug>
Thank you.
Daniel Barlow, for what you have done for me I declare you my
personal lisp hero.
See, you already got fanboy posts in cll.. must be a good sign.
Daniel Barlow <···@telent.net> writes:
> themselves. Or they can attempt to set up their Lisp systems using
> only tools and libraries that were available in 1998 and see how they
> get on. Good luck guys; I hear that CMUCL has just gained an x86
> backend, so you might be able to get it running on Linux. You may
> need to crosscompile from Alpha, though.
For the record, it's been pointed out to me that I was a couple of
years off on this particular bit: if you knew who to ask you could
have had an x86 cmucl back in 1996 or possibly even earlier. In fact
Sunsite is still hosting a fairly early version of Peter's Linux port,
dated 1997-10-31.
-dan
--
"please make sure that the person is your friend before you confirm"
>>>>> "Daniel" == Daniel Barlow <···@telent.net> writes:
Daniel> Daniel Barlow <···@telent.net> writes:
>> themselves. Or they can attempt to set up their Lisp systems using
>> only tools and libraries that were available in 1998 and see how they
>> get on. Good luck guys; I hear that CMUCL has just gained an x86
>> backend, so you might be able to get it running on Linux. You may
>> need to crosscompile from Alpha, though.
Daniel> For the record, it's been pointed out to me that I was a couple of
Daniel> years off on this particular bit: if you knew who to ask you could
Daniel> have had an x86 cmucl back in 1996 or possibly even earlier. In fact
Daniel> Sunsite is still hosting a fairly early version of Peter's Linux port,
Daniel> dated 1997-10-31.
In addition, the crosscompile from Alpha was originally used to get
the x86/FreeBSD port going. I don't know how the LInux version was
done, but I assume it was cross-compiled from the working x86/FreeBSD
version.
Ray
Mike Kozlowski wrote:
> It's not a substitute. Someone like me, who's trying out CL to see if
> it's worth getting deeply involved in, is in no position to do
> anything much toward getting CL's shit together. The people
> who can do that are those who have made significant contributions,
> have significant experience, and would command significant respect in
> the CL world.
Nope. There is an increasing number of beginners, and they seem to succeed.
> I'm just reading along, making the occasional post out of a frustrated
> sense that people are missing the point, and trying to figure out if
> there's even any desire on anyone's part to improve the situation; and
> I've been a bit dispirited when, for instance, reading the responses
> to Peter Seibel's eminently sensible and dead-on posts...
I don't have the impression that anyone says that a certain kind of
standardization would be a bad thing. It's rather that some of us think
that this is not going to happen anytime soon.
Another thing that newbies sometimes don't get right is that they are
overwhelmed by the possibilities that CL provides, and one immediate gut
reaction is the wish that things should be much simpler. However, one of
the notions in CL, as far as I perceive them, is that complexity should
not be hidden by some oversimplified abstractions, but rather that
programmers should be given all the rope they need in order to deal with
even exotic scenarios. That's why it's considered an expert language.
You have to know about the underlying issues anyway sooner or later, so
why hide them? Of course, this makes the stuff harder to grasp for
beginners, but at the same time it makes it easier to deal with in the
long run.
I know what I am talking about, I have been in a similar situation about
two years ago...
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Pascal Costanza wrote:
> Mike Kozlowski wrote:
>
>> It's not a substitute. Someone like me, who's trying out CL to see if
>> it's worth getting deeply involved in, is in no position to do
>> anything much toward getting CL's shit together. The people
>> who can do that are those who have made significant contributions,
>> have significant experience, and would command significant respect in
>> the CL world.
>
>
> Nope. There is an increasing number of beginners, and they seem to succeed.
Yep. It was Frank Goenninger (sp?) a Lisp newbie who ported Cello to
Linux. Frank reported that it was a fun way of learning Lisp. What
mattered most (it seems) is that Frank knows his way around Linux and
gcc and just plain programming pretty well.
My oft-repeated prediction is that Lisp libraries will come from newbies
who land on our shores, dig the language, miss the libraries, then build
them, probably with tired old Lispniks like Barlow grudgingly calling
out helpful advice from their rocking chairs on the cll porch.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> The problem with the melodramatic arguments for standardized FFI,
> networking, etc., is that they're overdone. The thing is, it really
> *isn't* very hard to port networking code.
A corollary to this is that, unless libraries are well designed *and
up to the task*, trying to use a library can result in one or more of:
wasting a lot of time trying to use it before giving up, wasting a lot
of time working around features it does not have, wasting a lot of
time extending it (usually badly), deciding it's no good and
implementing another library (usually also no good), living with a
program which doesn't work, or just getting annoyed and dispatching
black helicopters to deal with its author (this option is only open to
Kenny and me, of course).
And library design is very, very hard indeed. It's nearly as hard as
language design. I write a lot of Python at the moment, and this has
made it really obvious how hard it is. There are too many screwed up
inadequate Python libraries to mention here, I *often* find myself
thinking that maybe I should just reimplement something that works.
An example fromn the language is argument defaulting and arglists in
general: I never realised how good CL's argument passing design is
until I'd dealt with Python's awful botch.
Of course, most programmers (a) don't care if their program actually
works (just so long as it works in the four cases they test, it's OK),
or (b) would rather spend time doing yet another botched library
design, because this both avoids doing real work, and you can say
you're doing Open Source and thus ensure your place in heaven. Well,
that's not true, *most* programmers prefer to sit and complain,
because that avoids doing *anything*, but let's stick to the ones who
get something done. A small minority of programmers understand how
hard library design is, and of those, most (this is me) choose to do
the small amount of work you mentioned to just port their code, and a
few (this is about 2 people by now) design decent libraries.
Richard Gabriel had some interesting stuff to say about this - I
regret not having had more time to talk to him as I think he really
understood the problems.
Let me repeat: library design is very, very hard.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
>
> > The problem with the melodramatic arguments for standardized FFI,
> > networking, etc., is that they're overdone. The thing is, it really
> > *isn't* very hard to port networking code.
>
> A corollary to this is that, unless libraries are well designed *and
> up to the task*, trying to use a library can result in one or more of:
> wasting a lot of time trying to use it before giving up, wasting a lot
> of time working around features it does not have, wasting a lot of
> time extending it (usually badly), deciding it's no good and
> implementing another library (usually also no good), living with a
> program which doesn't work, or just getting annoyed and dispatching
> black helicopters to deal with its author (this option is only open to
> Kenny and me, of course).
Yeah, this is the reason I don't release my half-assed libraries that
are good enough for what I've done with them, and also part of why I
have so many of them -- the other part is that it's so easy to write
libraries in CL.
An interesting exception is the contribs in SBCL. Everything you'd
want isn't necessarily there, but they're well designed, so adding
what you need is easy. I spent maybe 20 minutes adding support for
anonymous mmaping, `fork', `wait', and `waitpid' to sb-posix. And
about as much time adding `socketpair' to sb-bsd-sockets. The next
time I need to add something to one of them, it'll be much faster.
Of course, 1/2 the hard work was already done, in that they're just
Lispier bindings to the POSIX and BSD Socket APIs.
> Let me repeat: library design is very, very hard.
Not that people shouldn't try, but I agree wholeheartedly.
Also, to any would-be library designers out there, read AMOP, please,
or any other book that covers open implementation. I will need to
extend your library, and I'd rather do it within the API.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: David Steuber
Subject: Re: Yaaawwwwwwwnnnnnn [was Re: Modernizing Common Lisp}
Date:
Message-ID: <87sme510up.fsf@david-steuber.com>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Also, to any would-be library designers out there, read AMOP, please,
> or any other book that covers open implementation. I will need to
> extend your library, and I'd rather do it within the API.
Amazon shipped my copy this morning. Also I'm getting Object-Oriented
Programming in Common Lisp: A Programmer's Guide to CLOS by Sonya
E. Keene.
I wonder if I'm going the right route though. I want to use sockets
and threads. SBCL seems to have what I need for that (I'm not worried
about portability yet, I just want to do it). But it seems I need to
have a better understanding of CLOS and error conditions along the
way.
It's like the useful subset of Lisp that I need is really big or
something. And two features I need are not ANSI.
If anyone tells me they mastered Lisp in 21 days, they will be readily
recognized by the Stanley hammer sticking out of their forehead.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber <·····@david-steuber.com> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Also, to any would-be library designers out there, read AMOP, please,
> > or any other book that covers open implementation. I will need to
> > extend your library, and I'd rather do it within the API.
>
> Amazon shipped my copy this morning. Also I'm getting Object-Oriented
> Programming in Common Lisp: A Programmer's Guide to CLOS by Sonya
> E. Keene.
I loved AMOP, but just as a warning, not everyone feels it; I think
Kenny Tilton called it "unreadable". Something to that effect.
> I wonder if I'm going the right route though. I want to use sockets
> and threads. SBCL seems to have what I need for that (I'm not worried
> about portability yet, I just want to do it). But it seems I need to
> have a better understanding of CLOS and error conditions along the
> way.
>
> It's like the useful subset of Lisp that I need is really big or
> something. And two features I need are not ANSI.
>
> If anyone tells me they mastered Lisp in 21 days, they will be readily
> recognized by the Stanley hammer sticking out of their forehead.
Heh. The first few Lisp programs I wrote, I got away with wrapping a
big IGNORE-ERRORS form around the main loop. We do need a good intro
to the condition system for those who can't get away with doing that
-- hopefully that chapter in "Practical Common Lisp" will fill the void.
I wouldn't sweat that sockets and threads aren't ANSI. I don't get
why some newbies worry about writing portable programs from day one;
whenever I'm a newbie, I throw portability to the wind until I'm
comfortable in the language. Never having gotten past newbie status
in Smalltalk, this is why I only know Squeak :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: David Steuber
Subject: Re: Yaaawwwwwwwnnnnnn [was Re: Modernizing Common Lisp}
Date:
Message-ID: <87iseyhm1z.fsf@david-steuber.com>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Heh. The first few Lisp programs I wrote, I got away with wrapping a
> big IGNORE-ERRORS form around the main loop. We do need a good intro
> to the condition system for those who can't get away with doing that
> -- hopefully that chapter in "Practical Common Lisp" will fill the void.
Yeah, I need to look at that chapter.
> I wouldn't sweat that sockets and threads aren't ANSI. I don't get
> why some newbies worry about writing portable programs from day one;
> whenever I'm a newbie, I throw portability to the wind until I'm
> comfortable in the language. Never having gotten past newbie status
> in Smalltalk, this is why I only know Squeak :-)
sb-bsd-socket and sb-thread not being ANSI doesn't really bother me.
Lack of good documentation that is inherent in something being ANSI
does. sb-bsd-socket is not too bad. There is a reasonable amount of
example code that should cover what I need. I hope. Also, it is a
Lispy layer over socket, so I can also look to the man page on socket
and see how things are translated. I am also able to restrict myself
to INET domain sockets for now.
With sb-thread, there is less documentation. The only example code
I've looked at so far is in the threads.impure.lisp file in the tests
directory for SBCL.
I also need to learn more about streams and things. I/O seems to be
important for a web application for some darn reason. ;-)
I'm trying to back off on my ambition a bit right now so that I can do
something with the small subset I do know. I'm not working on my
fractal code at the moment though as that is not what interests me at
this time.
I also find that I still spend more time reading about lisp than
programming lisp. I don't yet feel like I can just write software in
lisp yet.
Frankly, I'm stumped at the best way to become productive with lisp
quickly (well, quickly as possible). The learning curve feels more
like a learning cliff. I must be doing something wrong.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber <·····@david-steuber.com> wrote:
> I also find that I still spend more time reading about lisp than
> programming lisp. I don't yet feel like I can just write software in
> lisp yet.
I think this is a classic symptom: it's easy to be overwhelmed. CL also
quickly infects people with the desire to Do The Right Thing, which while
a noble goal is not necessarily the best way to learn.
Worse isn't better, but best is the worst enemy of good.
I think that while learning CL -- or any new thing for that matter -- it's
important to fluctuate between different modes of though: how do I deal
with this *now* / what am I really doing / what should I be doing, etc.
> Frankly, I'm stumped at the best way to become productive with lisp
> quickly (well, quickly as possible). The learning curve feels more
> like a learning cliff. I must be doing something wrong.
Write more, read less.
Keep a scratch directory or file of CL snippets that you don't even intend
to finish -- just something you type out while thinking about it for five
minutes.
When bored browse the CLHS -- don't even try to absorb it in one go, just
increase your "passive vocabulary" so that when you need something there's
a better chance you remember that it's already there...
When you feel an itch, scratch it: write trivial things in CL for your own
use, even if they end up in scratch/ and never get used again.
The more you write the more you get out of reading: eg. you see FOO in
CLHS and go "duh! so that's the way it's supposed to be done", as opposed
to "WTF is this for?".
Sometimes it's good to use a new language on a domain you're already
familiar with, sometimes not: you accidentally may set your sights at your
level of domain knowledge which may be so far ahead of your CL skills that
the impedance mismatch screws you up.
Write bottom up: if you want to do a multithreaded socket thingamajik with
a CLIM frontend and complex domain specific embedded language don't start
with the hard parts. Start with the bits you know how to do know, no
matter how trivial, even if you may end up painting yourself in a corner
-- you can always rewrite the early parts. Especially since first N lines
in any language tend to be embarassing later on you'd probably rewrite
them anyways. ;-)
Cheers,
-- Nikodemus
From: David Steuber
Subject: Re: Yaaawwwwwwwnnnnnn [was Re: Modernizing Common Lisp}
Date:
Message-ID: <87sme2ctdz.fsf@david-steuber.com>
·········@random-state.net writes:
> -- you can always rewrite the early parts. Especially since first N lines
> in any language tend to be embarassing later on you'd probably rewrite
> them anyways. ;-)
Only when N represents the cardinality of the set of all lines I have
written in the first place.
Have you seen the curried add?
(+ (+ (+ (+ (+ 1) 1) 1) 1) 1)
And some people say prefix notation is better than infix :-p
But you're right. It's time to code more even if it's dumb trivial
shit. With luck I'll learn how to program again (web apps have ruined
me). If all goes according to plan, I will be thinking in Lisp even
if I have to get a job programming in one of the inferior languages
like Java, C# (isn't that backwards Java?), or VB.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> sb-bsd-socket and sb-thread not being ANSI doesn't really bother me.
> Lack of good documentation that is inherent in something being ANSI
> does. sb-bsd-socket is not too bad. There is a reasonable amount of
> example code that should cover what I need. I hope. Also, it is a
> Lispy layer over socket, so I can also look to the man page on socket
> and see how things are translated. I am also able to restrict myself
> to INET domain sockets for now.
>
> With sb-thread, there is less documentation. The only example code
> I've looked at so far is in the threads.impure.lisp file in the tests
> directory for SBCL.
>
> I also need to learn more about streams and things. I/O seems to be
> important for a web application for some darn reason. ;-)
I think we have some of the same goals. I'm suffering through many of the
same issues. I finally had to back off a bit and let the sockets/threads
part drift a bit for now. I think the next thing for me is streams since,
as you point out, I/O is pretty important, not just for web apps, but most
other useful programs as well. ;-)
> I'm trying to back off on my ambition a bit right now so that I can do
> something with the small subset I do know. I'm not working on my
> fractal code at the moment though as that is not what interests me at
> this time.
>
> I also find that I still spend more time reading about lisp than
> programming lisp. I don't yet feel like I can just write software in
> lisp yet.
Me, too. I think this is somewhat natural, though. I'm finding that I'm
tearing through many books quickly, skimming, picking up the parts that are
interesting and moving on. I find that some of the best material to read is
raw Lisp code. That forces me back to the CLHS when I don't understand
something and it's a good way to pick up various idioms, etc. That said, I
know just what you're going through.
> Frankly, I'm stumped at the best way to become productive with lisp
> quickly (well, quickly as possible). The learning curve feels more
> like a learning cliff. I must be doing something wrong.
Like anything else, I think you have have to jump in and feel incompetent
for a while. It's that natural learning progression from concious
incompetence, concious competence, finally to unconcious competence. Right
now, I'm conciously incompetent. A bit more practice and I'll start feeling
a bit more competent. Then it'll finally blend to the point where it's all
just natural.
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
··········@tfeb.org (Tim Bradshaw) wrote in message news:<···························@posting.google.com>...
> An example fromn the language is argument defaulting and arglists in
> general: I never realised how good CL's argument passing design is
> until I'd dealt with Python's awful botch.
In case anyone thinks you're being an anti-Python jerk, just last week
someone asked me to critique his Python code for work -- when I asked
about his arglists, he was annoyed because he thought he got rid of
all those instances. Been biting him hard.
> A small minority of programmers understand how
> hard library design is, and of those, most (this is me) choose to do
> the small amount of work you mentioned to just port their code, and a
> few (this is about 2 people by now) design decent libraries.
Do you have an example of which libraries to watch out for?
From: Tim Bradshaw
Subject: Re: Yaaawwwwwwwnnnnnn [was Re: Modernizing Common Lisp}
Date:
Message-ID: <ey3r7tnpjsp.fsf@cley.com>
* Tayssir John Gabbour wrote:
> In case anyone thinks you're being an anti-Python jerk, just last week
> someone asked me to critique his Python code for work -- when I asked
> about his arglists, he was annoyed because he thought he got rid of
> all those instances. Been biting him hard.
Well, let me also say a good thing about Python: a couple of days ago
I converted a function which took 18 positional arguments to take all
KW args. No client code had to change at all.
> Do you have an example of which libraries to watch out for?
No, or, well, yes, but I need to go and look at them again before
being rude in public.
--tim
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> * Tayssir John Gabbour wrote:
> > Do you have an example of which libraries to watch out for?
>
> No, or, well, yes, but I need to go and look at them again before
> being rude in public.
I was actually wondering for GOOD libraries, not the bad ones. Sorry
if I was unclear. I'm just interested in learning what people consider
to be good design.
I can guess what bad design is like. ;)
We just had the second annual TPL (Trotskyist Programming League)
meeting this weekend.
Between consuming vodka, bad Bordeaux and actually quite decent
lobster mayonnaise, we managed to create three committees, spawn two
splinter groups, have one character assassination and even a couple
bouts of fisticuffs (followed, of course, by tearful reconciliations
and mutual promises of everlasting faithfulness to the cause, the
importance of which dwarfs all merely quotidian concerns).
Considering that only six people came to the meeting I found this
quite encouraging, even exhilarating. My hope for the next meeting is
that we will manage to actually get a second to the motion currently
on the floor to vote on rules of order.
Reading comp.lang.lisp I almost felt like the meeting was still going
on.
--
Fred Gilham ······@csl.sri.com
The spam folder --- you will never find a more wretched hive of scum
and villainy. We must be cautious.
Kenny Tilton wrote:
> Don't get me wrong. I said originally it would be lovely if the Library
> Standards Fairy would leave CL-FFI and CL-SOCKETS under our pillows
> tonight. Can't wait till morning!
I must've gotten you wrong. By my count, you've made three posts in this
thread. In the first, you changed the subject line to indicate your lack
of interest, you claimed that progressives are advocating that "Lispniks
should drop everything and get to work on" standardization, and stated
that you yourself are "simply not interested in all this crap about
standardizing x, y, and z."
The second was a jocular offer to hold the stakes in a paid-for voting
system. The third contained the post above, and signed off with another
smiley.
If you want to maintain your innocent's view about the Library Standards
Fairy (and Santa Claus), stay out of this thread, because we're
discussing grown-up secrets here! Don't worry, there will be a little
gift under the pillow soon, as long as you're good and you don't
disparage the Fairy, or tell the other children not to believe, as you
have been.
But if you're bad, Kenny, be warned that it might be a horse's head that
the Fairy leaves under the sheets for you! Be good, Kenny!
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> Kenny Tilton wrote:
>
>> Don't get me wrong. I said originally it would be lovely if the
>> Library Standards Fairy would leave CL-FFI and CL-SOCKETS under our
>> pillows tonight. Can't wait till morning!
>
>
> I must've gotten you wrong. By my count, you've made three posts in this
> thread. In the first, you changed the subject line to indicate your lack
> of interest, you claimed that progressives are advocating that "Lispniks
> should drop everything and get to work on" standardization, and stated
> that you yourself are "simply not interested in all this crap about
> standardizing x, y, and z."
I need a good quote deprecating the merits of consistency. Anybody got
one? Should involve hobgoblins.
Besides, I /am/ being consistent: my interest is not in standards, but
in the failure to communicate. I, as one implicitly criticized for
complacency with the current state of affairs, have answered with a
topspin lob: you now have to explain my protypical complacency!
>
> The second was a jocular offer to hold the stakes in a paid-for voting
> system. The third contained the post above, and signed off with another
> smiley.
>
> If you want to maintain your innocent's view about the Library Standards
> Fairy (and Santa Claus), stay out of this thread,
Hmm, first Jacek and now you sick the bouncers on me. Come to think of
it, there is not much else one can do with a well-placed topspin lob.
Clearly you two are from the Tonya Harding[1] School of Usenetspeak. May
I take the presence of these nice, big men helping me with my elbows as
your way of saying, "Good point."?
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> I need a good quote deprecating the merits of consistency. Anybody got
> one? Should involve hobgoblins.
Hah! Now Eminem fancies himself an Emerson!
> Besides, I /am/ being consistent: my interest is not in standards, but
> in the failure to communicate. I, as one implicitly criticized for
> complacency with the current state of affairs, have answered with a
> topspin lob: you now have to explain my protypical complacency!
Misrepresenting your earlier posts on a subject is not being
inconsistent, it's misrepresenting.
Dave Roberts is working to improve things, and your first post in this
thread savaged his efforts in a vulgar and condescending manner. Even on
Usenet, that's not the definition of complacency.
If you'd been just another yob, I'd have let the whole thing slide, as I
believe that some of the anti-progressive rants in this thread have been
so hilariously (and unintentionally) self-deprecating that they've
actually *bolstered* our cause by showing the ridiculous character of
some of those arrayed against us.
--
Cameron MacKinnon
Toronto, Canada
From: Kenny Tilton
Subject: (not so) New Cello Screenshot! [was Re: Yaaawwwwwwwnnnnnn [was Re: Modernizing Common Lisp}]
Date:
Message-ID: <wyUnc.62207$Nn4.14915620@twister.nyc.rr.com>
Viola!: ftp://common-lisp.net/pub/project/cello/pc4-fractal.png
Actually there is a bug manifested (and I just figured it out): the
"Just Shoot Me!" screen self-capture widget hides itself for a frame so
the screenshot won't show it. But I had to go outside the Cello
update/dataflow mechanism (or I got lazy) to make it work, and my
backdoor hack to hide the widget is being defeated because the display
list still draws the sucker.
The only thing new is the groovy sound effects (which you cannot hear)
and the frame rate, which appears in red at the top left of the window.
Again, thx to David Steuber for the lovely mandelbrot fractal used to
texture the sierpinski sponge fractal.
In the same directory is a re-release of PortaCello4, named PortaCello4u
to differentiate. Now includes UFFI and a reworked 'with-layers' macro
to be less stupid, in the hope of cornering an unreproducible error
involving that code reported by one user.
Back on the unproductivity front:
Cameron MacKinnon wrote:
> Kenny Tilton wrote:
>
>> I need a good quote deprecating the merits of consistency. Anybody got
>> one? Should involve hobgoblins.
>
>
> Hah! Now Eminem fancies himself an Emerson!
>
>> Besides, I /am/ being consistent: my interest is not in standards, but
>> in the failure to communicate. I, as one implicitly criticized for
>> complacency with the current state of affairs, have answered with a
>> topspin lob: you now have to explain my protypical complacency!
>
>
> Misrepresenting your earlier posts on a subject is not being
> inconsistent, it's misrepresenting.
Did you do that or did I? I am so confused.
>
> Dave Roberts is working to improve things, and your first post in this
> thread savaged his efforts in a vulgar and condescending manner.
Welcome to the standards process. besides, you listen to hip-hop twenty
four seven and see what comes out of your mouff. you're lucky I don't
pop you with my Glop.
Even on
> Usenet, that's not the definition of complacency.
>
> If you'd been just another yob, I'd have let the whole thing slide, as I
> believe that some of the anti-progressive rants in this thread have been
> so hilariously (and unintentionally) self-deprecating that they've
> actually *bolstered* our cause by showing the ridiculous character of
> some of those arrayed against us.
Here's the difference between the yobs and yabbos: youse guys are
yapping on cll, I extended UFFI for callbacks and unsupported CLs and
paid someone to hack CMUCL to support callbacks from C to Lisp. So while
you pie in the sky moon on a stick dreamers talk about a standards
process which will never happen, other Lispniks are in the trenches
creating the de facto standards of which you dream.
Speaking of which, I have work to do. I suggest you put down On Lisp,
buy a copy of Practical Lisp, and get to work. writing. lisp.
:) peace! out!
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <························@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> I need a good quote deprecating the merits of consistency. Anybody got
> one? Should involve hobgoblins.
"Indeed, even at this stage, I predict a time when there will be
mathematical investigations of calculi containing contradictions, and
people will actually be proud of having emancipated themselves from
consistence." Ludwig Wittgenstein (1930) Philosophical Remarks
"Do I contradict myself? Very well then I contradict myself (I am large,
I contain multitudes). Walt Whitman (1855) Leaves of Grass
"The only people who are consistent are dead people." - Lou Holtz
(football coach)
"Knowledge so conceived is not a series of self-consistent theories that
converges towards an ideal view; it is not a gradual approach to the
truth. It is rather an ever increasing ocean of mutually incompatible
(and perhaps even incommensurable) alternatives, each single theory...that
is part of the collection forcing the others into greater articulation
and all of them contributing, via this process of competition..." (p. 21
of Feyerabend, P. (1988). Against method (revised edition). London:
Verso.)
"Frege's axiomatization of logical theory in The Fundamental Laws of
Arithmetic and Quine's in Mathematical Logic were both inconsistent in
ways that did not reveal themselves to many who had used each
axiomatization extensively. (p. 249 of Cherniak, C. (1994).
Computational complexity and the universal acceptance of logic. In H.
Kornblith (Ed.), Naturalizing epistemology (2nd Ed) (pp. 239-260).
Cambridge, MA: MIT Press.)
"Unfortunately, or luckily, no language is tyrannically consistent. All
grammars leak." (p. 38 of Sapir (1921). Quoted on p. 57 of Duranti, A.
(1997). Linguistic anthropology. Cambridge: Cambridge University Press.)
[My quotation crate is deep...]
Sashank Varma <····@vanderbilt.edu> wrote:
+---------------
| Kenny Tilton <·······@nyc.rr.com> wrote:
| > I need a good quote deprecating the merits of consistency.
| > Anybody got one? Should involve hobgoblins.
...
| "Do I contradict myself? Very well then I contradict myself (I am large,
| I contain multitudes). Walt Whitman (1855) Leaves of Grass
+---------------
Good one! Though I suspect Kenny might have been looking for this one: ;-}
"A foolish consistency is the hobgoblin of little minds, adored by
little statesmen and philosophers and divines. With consistency a
great soul has simply nothing to do. He may as well concern himself
with his shadow on the wall. Speak what you think now in hard words,
and to-morrow speak what to-morrow thinks in hard words again, though
it contradict every thing you said to-day."
-- Ralph Waldo Emerson (in "Self-Reliance")
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Sashank Varma <····@vanderbilt.edu> wrote:
> +---------------
> | Kenny Tilton <·······@nyc.rr.com> wrote:
> | > I need a good quote deprecating the merits of consistency.
> | > Anybody got one? Should involve hobgoblins.
> ...
> | "Do I contradict myself? Very well then I contradict myself (I am large,
> | I contain multitudes). Walt Whitman (1855) Leaves of Grass
> +---------------
>
> Good one! Though I suspect Kenny might have been looking for this one: ;-}
>
> "A foolish consistency is the hobgoblin of little minds, ...
Mmmmm, hobgoblins! Too late though, I much prefer the pretension of "I
contain multitudes". Just have to reconcile it with my other pretension,
"just a simple programmer". Hmmm....
kt
From: Thomas Schilling
Subject: Re: Yaaawwwwwwwnnnnnn [was Re: Modernizing Common Lisp}
Date:
Message-ID: <opr7ujllfetrs3c0@news.CIS.DFN.DE>
Sashank Varma wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>> I need a good quote deprecating the merits of consistency. Anybody got
>> one? Should involve hobgoblins.
> "The only people who are consistent are dead people." - Lou Holtz
> (football coach)
Same in other words:
"Either you're consistent or you live." - Erich K�stner (author)
In article <··························@news.vanderbilt.edu>,
Sashank Varma <····@vanderbilt.edu> wrote:
> [My quotation crate is deep...]
I just ran across two more:
�To string incongruities and absurdities together in a wandering and
sometimes purposeless way, and seem innocently unaware that they are
abusrdities, is the basis of American art.� � Mark Twain
�It pulls back and forth all the time, and always has, even before I
thought about it. I would work flat for a while and then I would start
doing sculpture. The odd thing about the internal dialectic of
contradicting yourself, which is cathartic � the only thing that leads
to something new. I have to use contradiction in my work not only to
achieve something but to avoid something else. This sets me up for some
schitzophrenic tension. (p. 59 of Rose, B. (1987). An interview with
Robert Rauschenberg. New York: Vintage Books.)
Walt's is the best though...
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····························@twister.nyc.rr.com...
> I need a good quote deprecating the merits of consistency. Anybody got
> one?
"Constance is the hallmark of intellectual stagnation..."
> Should involve hobgoblins.
"...just like hobgoblins."
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Jacek Generowicz <················@cern.ch> wrote in message news:> You're presenting Paul Graham's Blub-user argument, albeit in a
> slightly different direction: I'm happy with my tools because they are
> what I have got used to; I've got used to the suffering my tools
> inflict on me to the extent that I don't really notice the pain any
> more.
>
> Just because you have been numbed to that particular pain, doesn't
> mean that others are not justifiably moved to consider how the status
> quo might be improved.
>
> If you are bored by people talking about improving the world in this
> particular way, then don't read the sodding thread ... more
> importantly, don't contribute to it.
Actually, I don't think that's what Kenny is really saying. Kenny,
like many others that would be labeled "hackers," seems to be
demonstrating a simple idea here.
Process is something we all can get paid to bend over backwards
dealing with. It's great for the corperate types, but it's not really
what Lisp needs right now. It's great that lisp got standardized, but
the reasons that it did so were unique to the time.
Now, if you want to move Lisp forwards, it's time to stop talking
about process and start writing code. While lisp experiences this
grassroots stage of its lifecycle, it doesn't need people *talking*
about code. It needs code. If your work is good, it will become
standard. If it is not, it will wither in obscurity. This is how every
other language trying to fill the same niche lisp is lumped in with
does things. It's how most software projects that are driven by
volunteer effort work. It's a very effective and proven model.
"Show me the code." Lisp is in a unique position. It's got all the
shine and potential of a newfangled language like Ruby, but it's got a
huge history, a standard, and a lot of cool features. To people like
me who are new to lisp, it almost seems like Lisp is being reborn. So
right now, Lisp is benefited by acting like a "new" language with lots
of grassroots effort. At the same time, it has all the advantages that
experienced programmers bring to the table. Lisp has the potential to
sweep all the contenders away, just like Ruby, Python, and other
languages in this class do. It just needs a developer base.
Kenny has been telling people this obliquely, and his "fairy" comments
neatly point out the problem to me. Code won't write itself. If you
need a library and no good one exists, write it. If a good one exists
but doesn't quite meet your needs, patch it. It's not like the rest of
the open source world has it much better off. They do this all the
time. It's expected. In fact, it's how projects are expected to evolve
in the long run! I'm not making this up, it's all in ESR's work (for
whatever that's worth).
Is it a waste of time to work on such projects? That depends on if you
do a good job or not. If you do a good job, Lisp gets another library
and an emergent standard will develop. If you do not, then your work
will be forgotten. So, do a good job and it's not a waste of time! :D
Dave Roberts wrote:
> That is, I have no doubt that everybody can use Lisp's great
> flexibility to go around and hack up their own compatibility layer for
> things like sockets (threads are a bit more difficult if you want to do it
> right since they interact with things like GC that are deep in the
> runtime), but should we? Is that a good use of our time?
You're right that things would be better if such libraries would be more
consistent across implementations. I just don't think that the time is
right for this. The kind of standardization you have in mind will happen
when there is enough momentum. That's all I am trying to say.
To put it differently: Where in the technology adoption life-cycle do
you think we are?
see, for example, http://ist-socrates.berkeley.edu/~fmb/articles/lifecycle/
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/
Pascal Costanza wrote:
>
> Dave Roberts wrote:
>
>> That is, I have no doubt that everybody can use Lisp's great
>> flexibility to go around and hack up their own compatibility layer for
>> things like sockets (threads are a bit more difficult if you want to do
>> it right since they interact with things like GC that are deep in the
>> runtime), but should we? Is that a good use of our time?
>
> You're right that things would be better if such libraries would be more
> consistent across implementations. I just don't think that the time is
> right for this. The kind of standardization you have in mind will happen
> when there is enough momentum. That's all I am trying to say.
Okay, fair enough.
> To put it differently: Where in the technology adoption life-cycle do
> you think we are?
>
> see, for example,
> http://ist-socrates.berkeley.edu/~fmb/articles/lifecycle/
Good question. My hunch is that for different pieces of the whole, we're in
all the various phases simultaneously. Some things are old hat and mature;
others not so much.
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Erann Gat <·········@flownet.com> wrote:
+---------------
| 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 <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Erann Gat <·········@flownet.com> wrote:
> 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
In article <··············@midnight.cs.hut.fi>,
·········@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 <·········@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.
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.
In article <···············@turing.uio.no>,
Martin Elster <·······@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 <·········@flownet.com> writes:
> Martin Elster <·······@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
--=-=-=
Martin Elster <·······@turing.uio.no> writes:
> Erann Gat <·········@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
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQBAm6KYrZy455Pig6QRAjPsAKCvjYDekjAfCwqd8B8DkgT0h6Dh6gCdH/9G
2EIu76a5zboC//zWJivlnO0=
=hpUZ
-----END PGP SIGNATURE-----
--=-=-=--
I personally hate both point-by-point and me-too! posts, but strangely this
turned out to be both. Oh well.
Will Hartung <·····@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
Will Hartung wrote:
> 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.
--
Cameron MacKinnon
Toronto, Canada
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?
--
; Matthew Danish <·······@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 wrote:
> 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.
--
Cameron MacKinnon
Toronto, Canada
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)?
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
In article <·····················@edtnps89>,
Wade Humeniuk <········@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.
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.
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?
--
Cameron MacKinnon
Toronto, Canada
> 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.
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
(·····@msoft.com)
Will Hartung wrote:
> 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.
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Will Hartung wrote:
> 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
Toronto, Canada
Cameron MacKinnon wrote:
>
> 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
Wade Humeniuk wrote:
> 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
Toronto, Canada
Cameron MacKinnon wrote:
>
> "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
On Fri, 07 May 2004 15:24:29 +0000, Wade Humeniuk wrote:
> 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
Frank A. Adrian wrote:
> 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
From: Friedrich Dominicus
Subject: Re: Modernizing Common Lisp
Date:
Message-ID: <877jvne4lg.fsf@fbigm.here>
"Frank A. Adrian" <·······@ancar.org> writes:
> (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.
On Sat, 08 May 2004 09:54:35 +0200, Friedrich Dominicus wrote:
> 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
Frank A. Adrian wrote:
>
> 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),
Are you over the disappointment that we guys are not Gods? That everyone
does not agree with you? That everyone does not have to agree with you?
Are you past that dark-night-of-the-soul thing about the entire state
of computing?
> 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."
>
You are getting off balance because of holding an extreme position. Nothing
is completely portable or non-portable (even between languages and OSes).
Quit with the images of doom and destruction, it is not that 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.
Paul Graham is not a God either.
Wade
On Sat, 08 May 2004 22:17:44 +0000, Wade Humeniuk wrote:
> Frank A. Adrian wrote:
> Are you over the disappointment that we guys are not Gods? That everyone
> does not agree with you? That everyone does not have to agree with you?
> Are you past that dark-night-of-the-soul thing about the entire state
> of computing?
Actually, I've never thought anyone on the computer industry were Gods.
And although I've occasionally had "that dark-night-of-the-soul thing"
with respect to the state of computing, it's more because people seem to
want to use the whole "less is more, worse is better thing" as an excuse
to justify their current system's suckification rather than actually
changing things to make them better.
> You are getting off balance because of holding an extreme position.
Wanting to make it easier to port code that uses a socket is an *extreme*
position? Wow! I guess if I want to make it easier to port code that
uses a regular expression, I must be clinically insane! Look over here at
the crazy man who wants to have useful facilities standardized within the
language! Again, what gain do you see from not having some of these
features standardized?
> Nothing is completely portable or non-portable (even between languages
> and OSes). Quit with the images of doom and destruction, it is not that
> way.
You are right - nothing is completely portable, but it can be more (or in
Lisp's case less) portable. And, again, I don't want portability, I want
standardization (Yes, it's for my ultimate goal of portability, but I
thought that was the whole idea behind Common Lisp - maybe I am wrong
about that...). As for images of doom and destruction, I do know that
unless Lisp moves forward, it will by definition stagnate. And history has
not been kind to languages that stagnate. Even the developers of Fortran
figured that out.
> Paul Graham is not a God either.
Who the hell said he was? I just said this thread let me understand a
portion of his argument. Not that your response has changed my mind in
any way. Yet again: Why do *you* think standardizing FFI's, threading, and
socket interfaces would be such a hideous turn of events?
faa
Frank A. Adrian wrote:
> Who the hell said he was? I just said this thread let me understand a
> portion of his argument. Not that your response has changed my mind in
> any way. Yet again: Why do *you* think standardizing FFI's, threading, and
> socket interfaces would be such a hideous turn of events?
I do not think it would be hideous. I never ever said that. I have
just said that I am not waiting around for it, nor am I shy of using
a commercial vendors offerings. The only hideous thing I can think
about is an intellectual bloodbath. I am not worried about the commercial
vendors, they are mostly there already, as well as CMUCL, SBCL. CLISP, no
idea on whether it is easy there.
To put in my vote now, Allegro Common Lisp's FFI, Allegro Common Lisp's
Sockets and Allegro Common Lisp's Multiprocessing.
They are the most complete, proven and functional.
What's your vote?
Wade
On Sat, 08 May 2004 23:11:48 +0000, Wade Humeniuk wrote:
> What's your vote?
My vote is to take a first step. To get vendors, library builders, and
users together to decide *which* features are ready for standardization.
But to do this honestly, the first task is to agree that providing
standardized access to more technology within this language would be a
good thing. I know there is, in parts of the Lisp community, a belief
that the language is already too large; that the 700+ page size of its
standard is one reason that is often given for Lisp's "lack of success" in
the marketplace (That this "lack of success" is a canard is another issue
for another day); that adding even more to the standard would make it even
more unwieldy. But when I look at the standard, the thing I see is a very
small language, with a simple external representation, minimal semantics
for representation of code as internal structures, a small set of control
primitives telling us how to dynamically interpret that code, a dynamic
typing system to describe primitive objects within those internal
structures, and a medium-sized set of these primitive types. The majority
of the standard (almost everything past Chapter 7) is what most people
would these days include in a standardized library specification. I guess
my point (for those who believe that Common Lisp is "too big") is that
most users understand the difference between library and language. They
don't hold the size of the libraries against that of the language (if it's
presented as such); they want standardization in both; they want maximal
functionality in the library portion.
The next thing to agree upon is that not all who promote additions to the
Lisp standard for modern features are spreading FUD about the language.
(As an aside - nor is the default stance deriding those who promote
addition of modern features as trolls particularly helpful.) Yes, there
are trolls who come to c.l.l who use this avenue as the start of an attack
on the language. But there are also those who are honest dealers who like
and use the language but would like to include these features to make the
language more pleasant to use. Recognize that attacks by trolls would not
sting so much if there were no truth in their arguments. But, facing
facts, it is undeniable that Lisp does not have a *standardized* access to
some modern programming facilities; that the lack of such facilities makes
using these features in portable applications more difficult (not
impossible, not terribly difficult, but *more* difficult than if
standardized facilities were there). It would not be an insurmountable
obstacle to using the language if these features were never included. It
would be *more* pleasant and easier to use the language if these facilties
*were* present.
The next thing to agree upon is that most folks who want these additions
do not want to tear down the edifice that is the standard. The standard
took a lot of work and tears across the entire community (or so I hear
:-). I (and I assume many who want additions) do not want to reconfigure
the language wholesale (as Paul Graham wants to do with ARC). I believe
in the standard as an initial basis for what is possible and want minimal
changes to said standard (especially in the core sections describing the
language). That being said, some of us believe that it would be a good
thing to extend the set of primitive types that a conforming
implementation would support, and that these additions would likely entail
some minimal changes to the specification and core language. So be it.
So my vote is to take a first step. To try to get repesentatives from
the major commercial implementors (Franz, Xanalys, MCL, Scieneer, Corman),
the major open source implementors (CLISP, CMUCL, SBCL), library builders
(CLOCC, PORT, UFFI, UncommonSQL, etc.), and users of the language together
in some forum to see if we can at least forge some agreement as to *which*
"modern" OS/library facilities have the maturity, commonality of
function, and broad usefulness to be standardized.
But again - that's my vote. What do others think?
faa
Frank A. Adrian wrote:
> So my vote is to take a first step. To try to get repesentatives from
> the major commercial implementors (Franz, Xanalys, MCL, Scieneer, Corman),
> the major open source implementors (CLISP, CMUCL, SBCL), library builders
> (CLOCC, PORT, UFFI, UncommonSQL, etc.), and users of the language together
> in some forum to see if we can at least forge some agreement as to *which*
> "modern" OS/library facilities have the maturity, commonality of
> function, and broad usefulness to be standardized.
>
> But again - that's my vote. What do others think?
Not interested. Count me out. I would rather appoint a
dictactor to decide on new standards. Someone who knows
and is committed to Lisp. My top choices are:
Kent Pitman
Erik Naggum
Christopher Stacey
Duane Rettig
As far as I know these people have been involved in a standardization
process like this for some time. I will defer any personal preference
to the dictator as I know the choice will not affect the way things
*really* now work.
Wade
Wade Humeniuk wrote:
> Frank A. Adrian wrote:
>
>> So my vote is to take a first step. To try to get repesentatives from
>> the major commercial implementors (Franz, Xanalys, MCL, Scieneer,
>> Corman),
>> the major open source implementors (CLISP, CMUCL, SBCL), library builders
>> (CLOCC, PORT, UFFI, UncommonSQL, etc.), and users of the language
>> together
>> in some forum to see if we can at least forge some agreement as to
>> *which*
>> "modern" OS/library facilities have the maturity, commonality of
>> function, and broad usefulness to be standardized.
>>
>> But again - that's my vote. What do others think?
>
>
> Not interested. Count me out. I would rather appoint a
> dictactor to decide on new standards. Someone who knows
> and is committed to Lisp. My top choices are:
>
> Kent Pitman
> Erik Naggum
> Christopher Stacey
> Duane Rettig
>
> As far as I know these people have been involved in a standardization
> process like this for some time. I will defer any personal preference
> to the dictator as I know the choice will not affect the way things
> *really* now work.
>
> Wade
One more thing. It costs ~$100US to vote, the winner receives all the
money to actually do the work.
Wade
Wade Humeniuk wrote:
> Wade Humeniuk wrote:
>
>> Frank A. Adrian wrote:
>>
>>> So my vote is to take a first step. To try to get repesentatives from
>>> the major commercial implementors (Franz, Xanalys, MCL, Scieneer,
>>> Corman),
>>> the major open source implementors (CLISP, CMUCL, SBCL), library
>>> builders
>>> (CLOCC, PORT, UFFI, UncommonSQL, etc.), and users of the language
>>> together
>>> in some forum to see if we can at least forge some agreement as to
>>> *which*
>>> "modern" OS/library facilities have the maturity, commonality of
>>> function, and broad usefulness to be standardized.
>>>
>>> But again - that's my vote. What do others think?
>>
>>
>>
>> Not interested. Count me out. I would rather appoint a
>> dictactor to decide on new standards. Someone who knows
>> and is committed to Lisp. My top choices are:
>>
>> Kent Pitman
>> Erik Naggum
>> Christopher Stacey
>> Duane Rettig
>>
>> As far as I know these people have been involved in a standardization
>> process like this for some time. I will defer any personal preference
>> to the dictator as I know the choice will not affect the way things
>> *really* now work.
>>
>> Wade
>
>
> One more thing. It costs ~$100US to vote, the winner receives all the
> money to actually do the work.
I vote for Peter Seibel. I have also volunteered to hold the voting
fees, so I have my $1000 right here in an envelope. Send yours along and
I'll add it to the kitty.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> I vote for Peter Seibel. I have also volunteered to hold the voting
> fees, so I have my $1000 right here in an envelope. Send yours along and
> I'll add it to the kitty.
We should also get a Diebold, online voting machine to keep track
of the vote. :) Or perhaps you would like to write a Cello
distributed app to collect the online votes? (And collect the
money by any major credit card)
How about calling elections for the New Lisp/FFI/Socket/Threaded Dictator now?
Give 30 days for people willing to do it get nominated. People can
present their platforms during a 60 day election.
The winner will receive the funds, $50,000 US minimum, to do the work.
The electorate will garauntee the minimum amount, by making
up any shortfalls in collection.
Wade
Wade Humeniuk <········@telus.delete.net> writes:
> We should also get a Diebold, online voting machine to keep track
> of the vote. :)
That would make George Bush the winner. No thanks!
:-)
--
(espen)
Wade Humeniuk <········@telus.delete.net> writes:
> One more thing. It costs ~$100US to vote,
Well, that's fine -- that's about tuppence in real money...
> the winner receives all the money to actually do the work.
... damn.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Wade Humeniuk wrote:
> Frank A. Adrian wrote:
>
>> So my vote is to take a first step. To try to get repesentatives from
>> the major commercial implementors (Franz, Xanalys, MCL, Scieneer,
>> Corman),
>> the major open source implementors (CLISP, CMUCL, SBCL), library builders
>> (CLOCC, PORT, UFFI, UncommonSQL, etc.), and users of the language
>> together
>> in some forum to see if we can at least forge some agreement as to
>> *which*
>> "modern" OS/library facilities have the maturity, commonality of
>> function, and broad usefulness to be standardized.
>>
>> But again - that's my vote. What do others think?
>
>
> Not interested. Count me out. I would rather appoint a
> dictactor to decide on new standards. Someone who knows
> and is committed to Lisp. My top choices are:
>
> Kent Pitman
> Erik Naggum
> Christopher Stacey
> Duane Rettig
>
> As far as I know these people have been involved in a standardization
> process like this for some time. I will defer any personal preference
> to the dictator as I know the choice will not affect the way things
> *really* now work.
>
That is an interesting proposition, but what about the folks at, say,
Digitool? MCL is a wonderful programming environment. Or what about
Will Newman and all the effort he put into making SBCL work?
Seems to me that we are touching on a deeper issue here. Some people
are for the "bazaar" and some people are for the "cathedral". I am for
the "mall". I.e. you need something in between.
I believe that Frank's idea is right. One representative per
implementation is necessary. Each of them is by definition "committed
to Common Lisp" and "knowledgeable about it". How to involve "users" in
the process is a matter of debate, but I believe it is necessary. My
idea is to have the local Lisp groups to elect a representative. Of
course, this may be sub-optimal as well, but, sincerely, I do not think
that the Python/Perl way is going to help here. And we do not have the
Java way to follow. We must invent something new.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Wade Humeniuk wrote:
> > Frank A. Adrian wrote:
> >
> >> So my vote is to take a first step. To try to get repesentatives from
> >> the major commercial implementors (Franz, Xanalys, MCL, Scieneer,
> >> Corman),
> >> the major open source implementors (CLISP, CMUCL, SBCL), library builders
> >> (CLOCC, PORT, UFFI, UncommonSQL, etc.), and users of the language
> >> together
> >> in some forum to see if we can at least forge some agreement as to
> >> *which*
> >> "modern" OS/library facilities have the maturity, commonality of
> >> function, and broad usefulness to be standardized.
> >>
> >> But again - that's my vote. What do others think?
> >
> >
> > Not interested. Count me out. I would rather appoint a
> > dictactor to decide on new standards. Someone who knows
> > and is committed to Lisp. My top choices are:
> >
> > Kent Pitman
> > Erik Naggum
> > Christopher Stacey
> > Duane Rettig
> >
> > As far as I know these people have been involved in a standardization
> > process like this for some time. I will defer any personal preference
> > to the dictator as I know the choice will not affect the way things
> > *really* now work.
> >
>
> That is an interesting proposition, but what about the folks at, say,
> Digitool? MCL is a wonderful programming environment. Or what about
> Will Newman and all the effort he put into making SBCL work?
(Having once pillaged from the SBCL code for the purposes of
constructing a new Lisp, Bill Newman gets my vote for Lisp saint of
the late 90's -- pulling apart CMUCL's build process was a feat of
immortal determination and patience)
> Seems to me that we are touching on a deeper issue here. Some people
> are for the "bazaar" and some people are for the "cathedral". I am for
> the "mall". I.e. you need something in between.
>
> I believe that Frank's idea is right. One representative per
> implementation is necessary. Each of them is by definition "committed
> to Common Lisp" and "knowledgeable about it". How to involve "users" in
> the process is a matter of debate, but I believe it is necessary. My
> idea is to have the local Lisp groups to elect a representative. Of
> course, this may be sub-optimal as well, but, sincerely, I do not think
> that the Python/Perl way is going to help here. And we do not have the
> Java way to follow. We must invent something new.
Huh, that sounds like a setup that could actually work. Folks with a
burning drive for new standardization efforts might want to setup a
meeting of this type at the next Lisp conference (that probably being
the most economical way to get a group like the above together).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Marco Antoniotti wrote:
>> As far as I know these people have been involved in a standardization
>> process like this for some time. I will defer any personal preference
>> to the dictator as I know the choice will not affect the way things
>> *really* now work.
>>
>
> That is an interesting proposition, but what about the folks at, say,
> Digitool? MCL is a wonderful programming environment. Or what about
> Will Newman and all the effort he put into making SBCL work?
>
My proposition, as I can see it, to move the focus away from supporting
technical positions, to move to supporting people instead. The
whole thing will not work if the people making the decisions are not
respected. When it comes down to which FFI, Socket or Multiprocessing
protocol is best, some of it will be arbritrary. The choice will come
down to, "it's good enough at this time". I am confident enough that a
single person can be found that is capable of looking the the whole
issue and making a good decision, there is no particular evidence that
a consenseous decision will be any better. Especially when it comes
to the FFI, Socket and Multiprocessing issues, it is pretty well known
how it will work (every implementation does things very similarly).
Will Digitool and Will Newman accept the decision? Maybe. That is
why I proposed that the dictator be given money to do the job, if he
has to pay vendors to do, then so be it, the dictator will decide.
If the dictator needs a staff to implement the decision, so be it,
its up to the person to do it, it is not enough to make a decision,
it takes a living personality to talk to and get people to do things.
A dictator elected for this specific issue would be the most
efficient use of money. It may be the dictator may not be a participant
on c.l.lisp.
> Seems to me that we are touching on a deeper issue here. Some people
> are for the "bazaar" and some people are for the "cathedral". I am for
> the "mall". I.e. you need something in between.
>
I hear you, but when it comes many technical issues one has to
subjugate one's personal preferences. We are all pretty intelligent
in the Lisp world and realize that how isomorphic many technical
solutions are and how non-technical issues affect how things are
done. But since this boils down to a human issues I would rather shift
to focus directly to putting trust in an actual human being, not
a process.
Wade
> I believe that Frank's idea is right. One representative per
> implementation is necessary. Each of them is by definition "committed
> to Common Lisp" and "knowledgeable about it". How to involve "users" in
> the process is a matter of debate, but I believe it is necessary. My
> idea is to have the local Lisp groups to elect a representative. Of
> course, this may be sub-optimal as well, but, sincerely, I do not think
> that the Python/Perl way is going to help here. And we do not have the
> Java way to follow. We must invent something new.
>
Marco Antoniotti <·······@cs.nyu.edu> wrote:
+---------------
| Seems to me that we are touching on a deeper issue here. Some people
| are for the "bazaar" and some people are for the "cathedral". I am for
| the "mall". I.e. you need something in between.
+---------------
Interesting... Can you say more? E.g., what characteristics in particular
do you have in mind that might distinguish a "mall" from a "bazaar"?
[And might this somehow relate to Frank Adrian's notion of "boutique
technology"? Given that boutiques are often found in malls... ;-} ]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
> +---------------
> | Seems to me that we are touching on a deeper issue here. Some people
> | are for the "bazaar" and some people are for the "cathedral". I am for
> | the "mall". I.e. you need something in between.
> +---------------
>
> Interesting... Can you say more? E.g., what characteristics in particular
> do you have in mind that might distinguish a "mall" from a "bazaar"?
>
> [And might this somehow relate to Frank Adrian's notion of "boutique
> technology"? Given that boutiques are often found in malls... ;-} ]
I think the primary difference would be in the applicability of local
zoning laws.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
On Wed, 12 May 2004 01:19:21 -0400, David Steuber wrote:
> I think the primary difference would be in the applicability of local
> zoning laws.
What are the most important three attributes of a successful business?
Location, location, and location...
faa
David Steuber wrote:
> ····@rpw3.org (Rob Warnock) writes:
>
>
>>Marco Antoniotti <·······@cs.nyu.edu> wrote:
>>+---------------
>>| Seems to me that we are touching on a deeper issue here. Some people
>>| are for the "bazaar" and some people are for the "cathedral". I am for
>>| the "mall". I.e. you need something in between.
>>+---------------
>>
>>Interesting... Can you say more? E.g., what characteristics in particular
>>do you have in mind that might distinguish a "mall" from a "bazaar"?
>>
>>[And might this somehow relate to Frank Adrian's notion of "boutique
>>technology"? Given that boutiques are often found in malls... ;-} ]
>
>
> I think the primary difference would be in the applicability of local
> zoning laws.
>
Metaphor for metaphor, you just hit the nail on the head :)
Cheers
marco
On Tue, 11 May 2004 19:06:22 -0500, Rob Warnock wrote:
> [And might this somehow relate to Frank Adrian's notion of "boutique
> technology"? Given that boutiques are often found in malls... ;-} ]
Oddly enough, I came up with the phrase "boutique technology", when trying
to come up with a name for a technology that is less than widely used, has
little industry support, and is not well funded. I started with
"marginalized technology", but I thought that phrase far too negative and
not reflecting the fact that the technology is better, that it has a
community of loyal supporters, and that it has a certain granting of
"specialness" associated with it. Given that I was interested in the
comparison of the boutique language that is Lisp vs. the Wal*Mart
languages that are (say) Java or C# or Perl "boutique technology" sums up
that cluster of attributes pretty well.
Some other examples of "boutique technology" (as a classic 57577 haiku
(see http://www.ahapoetry.com/haidefjr.htm), at that):
Apple on the desk;
Walking along in Prada;
Joy is hard to find -
BMW could help?
Maybe no, but maybe yes.
faa
"Frank A. Adrian" <·······@ancar.org> writes:
> But to do this honestly, the first task is to agree that providing
> standardized access to more technology within this language would be a
> good thing. I know there is, in parts of the Lisp community, a belief
[...]
> The next thing to agree upon is that not all who promote additions to the
> Lisp standard for modern features are spreading FUD about the language.
[...]
> The next thing to agree upon is that most folks who want these additions
> do not want to tear down the edifice that is the standard. The standard
I agree to all of the above.
> So my vote is to take a first step. To try to get repesentatives from
> the major commercial implementors (Franz, Xanalys, MCL, Scieneer, Corman),
> the major open source implementors (CLISP, CMUCL, SBCL), library builders
> (CLOCC, PORT, UFFI, UncommonSQL, etc.), and users of the language together
> in some forum to see if we can at least forge some agreement as to *which*
> "modern" OS/library facilities have the maturity, commonality of
> function, and broad usefulness to be standardized.
I also agree that this would be extremely important. But this takes
time and resources, i.e. actual work. Who volunteers?
Sitting on comp.lang.lisp and watching past and present discussions on
standardization does not suggest that this is going to come anytime
soon, but I would be happy to be proven wrong :) That's my only
perplexity about more or less formal 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
Hi Frank A. Adrian,
> I know there is, in parts of the Lisp community, a belief that the
> language is already too large; that the 700+ page size of its standard
> is one reason that is often given for Lisp's "lack of success" in the
> marketplace
I for one have little time for such belief. The Java Language
Specification (Second Edition) is 500+ pages and it is a one trick pony
enforcing mediocre object orientation. Even at this size the specification
only defines a process for discovering the functionality necessary to
build a program. Subsection 1.2 states "Throughout this book we refer to
classes and interfaces drawn from the Java and Java 2 platforms. Whenever
we refer to a class or interface which is not defined in an example in
this book using a single identifier /N/, the intended reference is to the
class or interface named /N/ in the package java.lang. We use the
canonical name (S6.7) for classes or interfaces from packages other than
java.lang."
If we ripped out all of the library functions in ANSI Common Lisp and
replaced them with a single paragraph reference to cl.* it is very likely
we would find that Common Lisp is a much smaller language than Java (Lisp
has much more regular notation, no statement/expression distinction and no
complicated rules of precedence).
The Java Language Specification spends two pages dealing with the `else'
ambiguity in if-then-else statements. In two pages ANSI Common Lisp
defines the entire reader algorithm.
The statement/expression distinction causes duplication of operator
definitions. Since `if' in Java only works as a statement and returns no
value a different notation has to be provided for if expressions, the `?
:' notation. This notation also has its own right-associative rule of
precedence where a?b:c?d:e means a?b:(c?d:e).
In the content that I snipped you made this point in the abstract. I've
just provided Java as some context.
It would be good to move Common Lisp's library functions into a standard
library, if only to demonstrate that the standardised parts of Common Lisp
are too small. There will be enough room to fit in a section on threads
like Chapter 17 of the Java Language Specification.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> I for one have little time for such belief. The Java Language
> Specification (Second Edition) is 500+ pages and it is a one trick pony
> enforcing mediocre object orientation.
That's fine, since Java's success isn't dependent on anyone but Sun
producing an implementation. Sure, there are some OSS groups trying
(and not closing in on the target as it runs away, at least not
quickly) but the non-Sun commercial implementations I've seen are
based on Sun's code. IBM's JRE, for instance... with WSAD they ship
source to the JRE libs, which are Sun's base with IBM mods.
Where the size of a standard causes problems is if the people who
wrote the standard aren't shipping an implementation on every
platform. I'd suggest that C++ lost so much mindshare to Java
because of _its_ huge standard and the problems rampant in
implementations for so long, making C practically the only portable
subset of C++.
--
Alan Shutko <···@acm.org> - I am the rocks.
Can you say critical mass? I knew you could.
Frank A. Adrian <·······@ancar.org> wrote:
> any way. Yet again: Why do *you* think standardizing FFI's, threading, and
> socket interfaces would be such a hideous turn of events?
I know you weren't addressing me, but...
I don't. I am, however rather sceptical about the ways some people seem to
expect it to happen, which loosely speaking fall into a few categories:
* "Let's call this library the standard" and its kissing cousin: "Let's
standardize all the Allegro interfaces" (Not meaning to slam Allegro
here.)
* "All the implementors should just get together and do it."
* "NCITS should do it."
Consider that original standardization process (afaik) came about from the
divergence of various lisps, and DARPA then strong-arming people to do
something about it. No such single body with enough fiscal mass and
interest in lisp exists right now.
NCITS J13 consists mostly of representatives of commercial vendors, and
even though the recent NCITS reports indicate a willingness to amend the
standard, or add technical reports to it, it also seems that the current
membership does not have the resources for such an undertaking.
As has been pointed out, picking a library and calling it a standard isn't
really all that great. The libraries may be good starting points, but at
the very minimum the documentation would have to be turned into a nice
specification.
Given all this it would seem obvious that likeliest source for "push for
standardization" would be the user community: individual who both pave the
way for standard by doing grunt-work (be that grunt work giving money or
providing your time and expertise), and lobbying implementors to come on
board and incorporate the emerging body of work.
All that said, how could such an effort be started?
--
One possibility would be to pick a feature you consider standardworthy,
looks at all the existing implementations: analyze their pros and cons,
see what is common, what is unique, and what no-one really deals with.
Talk with users of all these various implementations: what do they find
invaluable, what is too hard, what is missing, what seems unintuitive but
is really The Right Thing.
Then start consolidating these features with each other, writing a
specification for the future standard. Make compromises (and document
them) between the ideal and too-hard-to-implement, and consider the
aesthetics. What are core features the rest can be implemented on top of?
If it's sockets you're dealing with you should at this point realize that
the core features have nothing to do with sockets, and everything to do
with extensible streams and access to the platform sockets: your core
features are FFI and extensible streams. Make a compromise: a) leave
sockets alone for a while and write the FFI and stream specs first b)
design a socket interface that can be implemented on top of FFI and
extensible streams, but is specified without them c) consider sockets a
priority and write the spec without consideration of such details.
Along with this specification you should be working on a reference
implementation of it, one that preferably has a non-restrictive license so
that vendors will be able to incorporate it if they wish. Your
implementation would ideally run on several CLs and platforms, but say at
least two (sufficiently different) of each is almost the minimum.
Then present your work and propose it as a standard -- or as a starting
point of one. In your proposal analyze the costs of adoption
(relatively low if your reference implementation is good enough), and
outline the differences to existing implementations.
Wait for feedback, incorporate what's sane, and continue the advocacy.
Once there are standing standards-quality[1] proposals it makes sense to
get the standardization process itself going (be it unofficial or ANSI).
--
It's a shitload of work[2], a lot more then just writing a library.
If someone(s) are willing to do it, well and good, but I for one have the
gut feeling that at this time the effort is still better spent elsewhere
-- for example both portable and non-portable libraries. I don't think the
critical user-mass to make this viable is quite there right now, but who
knows where we are in six months or two years.
Cheers,
-- Nikodemus
[1] Actually, there are. See for example SPLIT-SEQUENCE. It's much much
more ready for standardization then UFFI, ASDF, or CL-PPCRE. The essential
difference is that it has a spec and a reference implementation, not a
library and documentation. This difference is not "just words".
[2] Granted, a lot less if you're working on standardizing
WITH-GENSYMS/WITH-UNIQUE-NAMES. ;-)
In article <··············@midnight.cs.hut.fi>,
<·········@random-state.net> wrote:
>As has been pointed out, picking a library and calling it a standard isn't
>really all that great. The libraries may be good starting points, but at
>the very minimum the documentation would have to be turned into a nice
>specification.
Fuck specs. Specs are nice for things where multiple implementations
are needed -- the whole point of XML, for instance, is that there will
be a zillion XML parsers, so the syntax needs to be exacting -- but
for things where one implementation is perfectly fine, an
implementation standard is better than a specification.
Formal standards are useful to the extent that people use them; de
facto standards are useful to the same extent. If everyone who does
serious regex work with CL uses CL-PPCRE, then CL-PPCRE is just as
much a standard in the CL world as, er, Perl is in the Perl world.
If not, not. Both of these things are true no matter what ANSI says.
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski wrote:
> be a zillion XML parsers, so the syntax needs to be exacting -- but
> for things where one implementation is perfectly fine, an
> implementation standard is better than a specification.
I believe there are many people (like me) who'd say that a proper,
preferably formal specification is more valuable than a particular
self-defining implementation, even if the standardized specification is
not as powerful, or flexible as the informal implementation counterpart,
or if it has some flaws.
That's because with a specification, you usually have choice -- you can
select from at least two implementations. And the API is more stable
over time. Standards don't change every half year (or every release of
the defining implementation). This also pertains to whole programming
languages. A reason why I, for example, prefer Standard ML over OCaml,
although the latter is arguably more feature rich, and gets updated a
lot more often (which I do not necessarily consider an advantage). I
simply do not like definition by examples. Maybe not many people think
like that, though, I don't know.
> facto standards are useful to the same extent. If everyone who does
> serious regex work with CL uses CL-PPCRE, then CL-PPCRE is just as
> much a standard in the CL world as, er, Perl is in the Perl world.
Fine. Then let's have at least two implementations of "CL-PPCRE", of
which the original one may be one, of course. And they should
synchronize their work somehow, or at least roughly work out a course on
how to do things, or how to implement stuff.
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
Matthias Buelow <···@mukappabeta.de> writes:
> Mike Kozlowski wrote:
>
>> be a zillion XML parsers, so the syntax needs to be exacting -- but
>> for things where one implementation is perfectly fine, an
>> implementation standard is better than a specification.
>
> I believe there are many people (like me) who'd say that a proper,
> preferably formal specification is more valuable than a particular
> self-defining implementation, even if the standardized specification
> is not as powerful, or flexible as the informal implementation
> counterpart, or if it has some flaws.
> That's because with a specification, you usually have choice -- you
> can select from at least two implementations. And the API is more
> stable over time. Standards don't change every half year (or every
> release of the defining implementation). This also pertains to whole
> programming languages. A reason why I, for example, prefer Standard
> ML over OCaml, although the latter is arguably more feature rich, and
> gets updated a lot more often (which I do not necessarily consider an
> advantage). I simply do not like definition by examples. Maybe not
> many people think like that, though, I don't know.
>
>> facto standards are useful to the same extent. If everyone who does
>> serious regex work with CL uses CL-PPCRE, then CL-PPCRE is just as
>> much a standard in the CL world as, er, Perl is in the Perl world.
>
> Fine. Then let's have at least two implementations of "CL-PPCRE", of
> which the original one may be one, of course. And they should
> synchronize their work somehow, or at least roughly work out a course
> on how to do things, or how to implement stuff.
What's the advantage of having two separate implementations if the one
that already exists is written in portable Common Lisp and is licensed
in such a way that if Edi abandons the project or goes insane someone
else can take it over, forking if necessary?
I suppose if one's goal is to have a formal standard having at least
two independent implementations would be a good test of how clear the
standard is. But if one's goal is to actually have a usable regexp
library is there some *benefit* to having two?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> I suppose if one's goal is to have a formal standard having at least
> two independent implementations would be a good test of how clear the
> standard is. But if one's goal is to actually have a usable regexp
> library is there some *benefit* to having two?
Of course not if it's just a recommended piece of software of a lose,
community-based collection of code (or something.)
Maybe it's just my idea that perfection cannot be reached unless a
somewhat suboptimal standard exists, that represents the intersection of
several implementations, and people start ranting on newsgroups how
deficient the standard is, and how it's holding back the spread of
featuritis. :)
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
On Fri, 14 May 2004 23:57:29 +0200, Matthias Buelow <···@mukappabeta.de> wrote:
> Fine. Then let's have at least two implementations of "CL-PPCRE",
> of which the original one may be one, of course. And they should
> synchronize their work somehow, or at least roughly work out a
> course on how to do things, or how to implement stuff.
Go ahead and create another implementation, that's fine with me... :)
Edi.
Edi Weitz wrote:
>>Fine. Then let's have at least two implementations of "CL-PPCRE",
>>of which the original one may be one, of course. And they should
>>synchronize their work somehow, or at least roughly work out a
>>course on how to do things, or how to implement stuff.
>
> Go ahead and create another implementation, that's fine with me... :)
Well, you said you were not to keen on it becoming The Standard, anyways. :)
--
Matthias Buelow; ···@{mukappabeta,informatik.uni-wuerzburg}.de
From: Friedrich Dominicus
Subject: Re: Modernizing Common Lisp
Date:
Message-ID: <8765b6ugdv.fsf@fbigm.here>
"Frank A. Adrian" <·······@ancar.org> writes:
>
> 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?
Well what's the difference between unzipping (do you really mean
zip-format) and having a command line which say (load-my-system) which
might be a function in a file?
>
> 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?
Well fortunatly that stuff works better than most common lisp
libraries. Why are the "dump" Unix guy able to get all this tools
running together and be useful-out-of-the-box and the Lisp guys
not. So if I had the choice between somthing that works usually or
does just work by accident. I prefer the first one.
> 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".
Well than use a language in which you find that. Good luck.
>
> 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
Well that is typical Common Lisp hatred obviously. You
>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.
So what there is not standard way for that in most languages. Does
that harm? No. People use their tool and whatever they found. But you
want to
- have it all at hand
- with a standard (which other have to implement for you)
- and probably it does not have to cost anything.
You can get what you want in you Lisp but not that is not "good"
enough it has to work on the neighbours Lisp too. So what you do is
asking that everything is "better" in Common Lisp and while this is
not done for you, you are ranting. That's not what I understand under
good style.
> 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.
Well I have to work hard in any language to get things portable. And
why should it matter to me. If the software does what it should for
me, that is the point. If it's non-portable why should I care? Again
if I get the pieces together why should I bother with someon elses
functinality?
> Oh yeah, and user community likes it this
> way and will fight hammer and tong to keep it this way."
No they are ranting and just say "Hey Common Lisp is cool, but you can
not do "modern" programming in it", which is just spreading FUD.
--
Please remove just-for-news- to reply via e-mail.
On Sun, 09 May 2004 10:57:48 +0200, Friedrich Dominicus wrote:
> No they are ranting and just say "Hey Common Lisp is cool, but you can
> not do "modern" programming in it", which is just spreading FUD.
No, I have never said that you cannot do modern programming in it. I
have and I do. I only say that the language has no *standard* modern
facilities. My question (which I still have had no actual answer of) is
*WHY* do you think that standardizing these items would be *SUCH* a
hideously bad thing? Why is it that any time anyone asks about it, they
get shouted down as a "Lisp hater"?
faa
Friedrich Dominicus wrote:
> 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, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Cameron MacKinnon wrote:
>
> 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
Antony Sequeira wrote:
> 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, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Antony Sequeira wrote:
> 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
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> wrote:
> 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
·········@random-state.net wrote:
> 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 <··········@clearspot.net> wrote:
> 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
--=-=-=
·········@random-state.net writes:
>
> 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)
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQBAm5D4rZy455Pig6QRAvzCAKCwn4PHum4tzuSLqEJlDucmv/n07gCfQJgv
2PUdBFISUr62ibU9y8JURLM=
=VMD8
-----END PGP SIGNATURE-----
--=-=-=--
Cameron MacKinnon <··········@clearspot.net> writes:
> 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
Marc Spitzer wrote:
> 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?
--
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
I pulled the pin on this hand grenade, so I might as well jump in to the
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, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog
Dave Roberts <·············@re-move.droberts.com> writes:
> 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.
David Steuber wrote:
> 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
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> 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.
On Fri, 07 May 2004 08:43:40 -0400, Cameron MacKinnon wrote:
>> 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.
The problem with native threads is that memory allocation and GC use a
shared heap, and thus would appear to require a lock, which would kill
performance if implemented naively. So some tricks must be played to avoid
some amount of locking, like having a separate part of heap for each thread
(but what if the GC was not a copying GC?).
Either all threads must be stopped for GC (how to ensure that all
reach a safe point?) or... well, I have no idea how to make a "true"
multithreaded GC without obtaining a lock for each allocation and setq,
which would be bad.
Userspace threads seem to be much simpler. With their own drawbacks
(having to do everything in non-blocking mode, which might be a problem
for third-party native libraries).
Another complication: dynamic bindings should be thread-local.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Either all threads must be stopped for GC (how to ensure that all
> reach a safe point?) or... well, I have no idea how to make a "true"
> multithreaded GC without obtaining a lock for each allocation and setq,
> which would be bad.
If you have an atomic compare-and-set-if-eq instruction (which the x86
has), then you can allocate storage by fetching the current frontier
value, computing the new frontier, and atomically updating the value
(trying again if someone else changed it in between). This is
essentially optimistic locking at the processor-word level, but
because it is supported by hardware it is reasonably fast.
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
+---------------
| Either all threads must be stopped for GC (how to ensure that all
| reach a safe point?) or... well, I have no idea how to make a "true"
| multithreaded GC without obtaining a lock for each allocation and setq,
| which would be bad.
+---------------
1. You can have a per-thread "nursery" (non-moving generation 0) and
allocate from that without thread locks until full, *then* do a
"stop-the-world" minor GC.
2. Using a card marking GC, a SETQ software write barrier doesn't need
locks (that is, provided that the memory system is coherent w.r.t.
writes at some small level of granularity, preferably bytes, but if
not, then at least words -- all normal SMP and ccNUMA systems provide
at least this).
+---------------
| Another complication: dynamic bindings should be thread-local.
+---------------
That's true even for user-space "green" threads, and should be considered
a solved problem. [All the major implementations already do that.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Wade Humeniuk wrote:
> Cameron MacKinnon wrote:
>
>>
>> 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?
Some men see things as they are and say "Why?"
I dream things that never were and say "Why not?"
(Robert F. Kennedy)
Andr�
--
Andr� Thieme wrote:
> Some men see things as they are and say "Why?"
> I dream things that never were and say "Why not?"
> (Robert F. Kennedy)
Perhaps Robert F Kennedy said that, but George Bernard Shaw
said it first. More precisely, in his play "Back to Methuselah"
those words are spoken by, IIRC, the serpent in the Garden of
Eden.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> Andr� Thieme wrote:
>
>
>>Some men see things as they are and say "Why?"
>>I dream things that never were and say "Why not?"
>>(Robert F. Kennedy)
>
>
> Perhaps Robert F Kennedy said that, but George Bernard Shaw
> said it first. More precisely, in his play "Back to Methuselah"
> those words are spoken by, IIRC, the serpent in the Garden of
> Eden.
Yes, this is correct.
I did some research to be more certain before posting this quote and I
was also thinking about giving credits to the original poster. For some
reason I didn't do it, but now I am glad that you added it, thanks.
Kennedy just made a slight different wording (than G.B. Shaw).
Andr�
--
Dave Roberts <·············@re-move.droberts.com> said:
>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.
Dave Roberts wrote:
> 1. To help Lisp developers compete with Java and Python developers, the Lisp
> camp needs a good set of ready-made library functionality.
If you're trying to catch up with Java, your best efforts will be out of
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
Dave Roberts <·············@re-move.droberts.com> wrote in message news:<·······················@attbi_s54>...
> 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.
Hmm, I retract my ill-tempered post to which I am replying; I had felt
I wasted quite a few minutes of my life in an earlier thread where I
got the impression it was simply a debate.
I have no real opinion on this issue except that perhaps the current
formal standard has a timeless quality due to its generality; and I
hope no major, limiting alterations are made to it in this age of
commodity hardware. A more lightweight channel of "standardization"
would be preferable, because language can perhaps limit imagination.
-- Tayssir
···········@yahoo.com (Tayssir John Gabbour) wrote in message news:<····························@posting.google.com>...
> Dave Roberts <·············@re-move.droberts.com> wrote in message news:<·······················@attbi_s54>...
> > 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.
Dave Roberts <·············@re-move.droberts.com> wrote in message news:<·······················@attbi_s54>...
> 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.
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.)
On further reflection based on discussion in this thread I have
changed my mind about standardization. While the Common Lisp
ANSI have been good (I am not even sure it is anymore), it
was forced upon the Lisp community by DARPA. Meant to
unite the Lisp community when it came to (I suppose)
military programming. But reading about the anecdotes
about what happened after, the Interlisp people getting
pissed and leaving, Paul Graham practically dropping out
of the Common Lisp scene, this attempt to unite everyone
just ended up splitting up everyone. This seems to be the
way of things, when things reach their zenith they fall apart.
Maybe the only real computer language standard (that is forced
by the natural order of things, not artificial constructs)
is that code is written in a language and a
computer program makes it happen. That may be all there is. Just
as it is impossible to standardize a natural language, it
may be impossible to standardize a computer language. An
attempt to standardize a language is an attempt to harden a
human mind. Minds will rebel against it. Common practices
build up over time, real innovation is the small aha! and then
we move on.
So now I am on the side of no standardization, just implementation,
and will try leave everything else in the dust.
Wade
Wade Humeniuk <········@telus.delete.net> writes:
> On further reflection based on discussion in this thread I have
> changed my mind about standardization. While the Common Lisp
> ANSI have been good (I am not even sure it is anymore), it
> was forced upon the Lisp community by DARPA. Meant to
> unite the Lisp community when it came to (I suppose)
> military programming. But reading about the anecdotes
> about what happened after, the Interlisp people getting
> pissed and leaving, Paul Graham practically dropping out
> of the Common Lisp scene, this attempt to unite everyone
> just ended up splitting up everyone.
I remember that most of us at LMI thought that Common Lisp was a
piss-poor, irritating substitute for a `real' Lisp like Zetalisp. The
Common Lisp committee seemed determined to reject about half of
Zetalisp a-priori in order to be `conservative'. And it didn't seem
to matter *what* half, just so long as half the functionality was
missing.
This is not to cast aspersions on the *members* of the committee! I
would be surprised if any member would have said `ya know, CLtL 1 is
*much* better than what I was using before'. With twenty years of
hindsight, it is clear that the committee did an excellent job of
finding a core common subset of the various implementations that could
be stably supported for a very long time.
From: Friedrich Dominicus
Subject: Re: Modernizing Common Lisp
Date:
Message-ID: <87sme8kyv5.fsf@fbigm.here>
Joe Marshall <···@ccs.neu.edu> writes:
>
> I remember that most of us at LMI thought that Common Lisp was a
> piss-poor, irritating substitute for a `real' Lisp like Zetalisp. The
> Common Lisp committee seemed determined to reject about half of
> Zetalisp a-priori in order to be `conservative'.
Nope Zetalisp does not had CLOS...
Hope your day will get nicer.
Friedrich
--
Please remove just-for-news- to reply via e-mail.
>>>>> On Mon, 10 May 2004 18:53:18 +0200, Friedrich Dominicus ("Friedrich") writes:
Friedrich> Joe Marshall <···@ccs.neu.edu> writes:
>>
>> I remember that most of us at LMI thought that Common Lisp was a
>> piss-poor, irritating substitute for a `real' Lisp like Zetalisp. The
>> Common Lisp committee seemed determined to reject about half of
>> Zetalisp a-priori in order to be `conservative'.
Friedrich> Nope Zetalisp does not had CLOS...
The Symbolics version had legacy Flavors, New Flavors (which was a
function-oriented, as opposed to message-passing, object system very
much like CLOS), and CLOS. New code was all written in New Flavors.
From: Friedrich Dominicus
Subject: Re: Modernizing Common Lisp
Date:
Message-ID: <87brkuxmy9.fsf@fbigm.here>
······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Mon, 10 May 2004 18:53:18 +0200, Friedrich Dominicus ("Friedrich") writes:
>
> The Symbolics version had legacy Flavors, New Flavors (which was a
> function-oriented, as opposed to message-passing, object system very
> much like CLOS)
Well to some extend yes, but no mutiple-dispatch, and CLOS was
definitly added later and not part of Zetalisp before.
>, and CLOS. New code was all written in New Flavors.
Well I see a mixture out of Flavours, New Flavors and Common Lisp...
Have a nice hacking
Friedrich
--
Please remove just-for-news- to reply via e-mail.
>>>>> On Wed, 12 May 2004 06:56:46 +0200, Friedrich Dominicus ("Friedrich") writes:
Friedrich> ······@news.dtpq.com (Christopher C. Stacy) writes:
>>>>>>> On Mon, 10 May 2004 18:53:18 +0200, Friedrich Dominicus ("Friedrich") writes:
>>
>> The Symbolics version had legacy Flavors, New Flavors (which was a
>> function-oriented, as opposed to message-passing, object system very
>> much like CLOS)
Friedrich> Well to some extend yes, but no mutiple-dispatch, and CLOS was
Friedrich> definitly added later and not part of Zetalisp before.
Before what? CLOS was certainly there years before there
was an ANSI standard (while it was still in process).
At least internally at Symbolics, but I think it was released.
CLOS didn't come out of thin air: it's a cross between
Common LOOPS and New Flavors.
>> , and CLOS. New code was all written in New Flavors.
Friedrich> Well I see a mixture out of Flavours, New Flavors and Common Lisp...
"Well" makes it sound like you are disagreeing with what I said,
which is that old code was written in Flavors and new code was
written in New Flavors. (Except on the ANSI-only platforms,
but those were only available on contract, to certain customers.)
I'm just recalling what we did, not trying to guess from
looking at some code release.