It is 13 years since the CL ANSI standard and still it hasn't been
revised. Are there any specific plans for it? Isn't this acting as a
hampering point in such a cool programming language?
·············@gmail.com" <············@gmail.com> wrote on 16 Mar 2007 11:4:
> It is 13 years since the CL ANSI standard and still it hasn't been revised.
Guess they did a pretty good job the first time.
> Are there any specific plans for it?
No.
> Isn't this acting as a hampering point in such a cool programming language?
No.
Do you have some specific complaint with the current standard?
What is broken that needs to be fixed?
(BTW: I'm well aware of the fact that some parts could be improved or
extended. But I object to your assumption that change is automatically good,
or that lack of change is evidence of a problem.)
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Diplomacy is the art of saying "nice doggy" until you can find a rock.
On Mar 16, 2:11 pm, Don Geddis <····@geddis.org> wrote:
> Do you have some specific complaint with the current standard?
> What is broken that needs to be fixed?
Isn't it obvious?
What needs to be fixed is the excessive passage of time since the last
standard.
:)
Don Geddis wrote:
> ·············@gmail.com" <············@gmail.com> wrote on 16 Mar 2007 11:4:
> > It is 13 years since the CL ANSI standard and still it hasn't been revised.
>
> Guess they did a pretty good job the first time.
Googling this newsgroup for Kent Pitman "We ran out of time" turns
up some hits, it turns out. But that means nothing because we know
a priori that the CL spec was divinely inspired.
> > Are there any specific plans for it?
>
> No.
True enough. It is worth mentioning in this context that the reasons
for not updating the spec are entirely political, not technical.
> > Isn't this acting as a hampering point in such a cool programming language?
>
> No.
>
> Do you have some specific complaint with the current standard?
> What is broken that needs to be fixed?
The spec is weak on stuff around the edges: file system stuff,
floating point, character sets come to mind. Implementations can and
do
make different choices, which is a source of endless fun for anyone
trying
to write portable code.
> (BTW: I'm well aware of the fact that some parts could be improved or
> extended. But I object to your assumption that change is automatically
> good, or that lack of change is evidence of a problem.)
There is no shortage of other evidence, though.
You may return to your customary self-congratulation at this time.
Robert Dodier
On 2007-03-19 03:42:56 +0000, "Robert Dodier" <·············@gmail.com> said:
> True enough. It is worth mentioning in this context that the reasons
> for not updating the spec are entirely political, not technical.
They are largely financial actually. Or, to be precise: the cost of
updating it far exceeds the technical benefits of doing so.
Of course If there *were* a strong movement to update it, I expect we'd
see a lot of people producing proposed fixes to the bits they don't
like rather than whining on cll that someone else isn't doing it for
them. Or did I mistake Lisp programmers for people again?
--tim
On Mar 16, 7:42 pm, ·············@gmail.com" <············@gmail.com>
wrote:
> It is 13 years since the CL ANSI standard and still it hasn't been
> revised. Are there any specific plans for it? Isn't this acting as a
> hampering point in such a cool programming language?
Common Lisp is a savage beast with many battle scars, some of them
dozens of years old. It would be prettier if it didn't, but no one
dares to get close enough to mend them.
Once you unleash it, its immense power is barely diminished by those
pesky old bruises anyways.
Common Lisp is a huge language (which is part of the reason why
it's so damn useful) and parts of it aren't as elegant as they could
be, but even 13 years after the standard was finished it's still
way ahead of most languages. A revision of the standard wouldn't
help adoption all that much; although the hype it would bring
wouldn't hurt either. Like Harald said, however, it's far too
expensive to be worth the effort.
Regards,
Joel
On 16 Mar 2007 15:29:28 -0700, "Joel Wilsson" <············@gmail.com> said:
| ...
| Common Lisp is a savage beast with many battle scars, some of them
| dozens of years old. It would be prettier if it didn't, but no one
| dares to get close enough to mend them.
| Once you unleash it, its immense power is barely diminished by those
| pesky old bruises anyways.
Hear, hear!
(By the way, this mighty warrior has a cousin, a beautiful
princess...)
---Vassil.
--
Definitely worth seeing: "Das Leben der Anderen" ("The Lives of Others").
A better language doesnt necessarily mean it can't be improved.Strife
for perfection is always desirable.
Why it necessarily has to be an expensive process? All we need is a
small group of good developers who can informally undertake this
project.
Vassil Nikolov wrote:
> On 16 Mar 2007 15:29:28 -0700, "Joel Wilsson" <············@gmail.com> said:
> | ...
> | Common Lisp is a savage beast with many battle scars, some of them
> | dozens of years old. It would be prettier if it didn't, but no one
> | dares to get close enough to mend them.
>
> | Once you unleash it, its immense power is barely diminished by those
> | pesky old bruises anyways.
>
> Hear, hear!
>
> (By the way, this mighty warrior has a cousin, a beautiful
> princess...)
>
> ---Vassil.
>
>
> --
> Definitely worth seeing: "Das Leben der Anderen" ("The Lives of Others").
On 2007-03-17 02:41:36 -0400, ·············@gmail.com"
<············@gmail.com> said:
> A better language doesnt necessarily mean it can't be improved.
I think we all agree on this point, but you misunderstand the other
issue of cost.
> Strife
strife = conflict
strive = to make an effort
> for perfection is always desirable.
> Why it necessarily has to be an expensive process?
Because the Common Lisp standard is an ANS (American National
Standard). ANSI requires certain things if a standard is to be revised:
<Essential Requirements Jan3107>
If you take a look at this document you'll realize that complying with
it is a time consuming and costly proposition for all the stakeholders
which would include, at a minimum, all of the major commercial and open
source implementors of common lisp.
> All we need is a
> small group of good developers who can informally undertake this
> project.
Then all you would end up with is an informal document that no one
would be required to implement or adhere to if they wanted to call
their implementation "ANSI Common Lisp." Since no one would be required
to implement it or adhere to it, it would not be a standard.
On 2007-03-17 06:59:53 +0000, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> said:
> Because the Common Lisp standard is an ANS (American National
> Standard). ANSI requires certain things if a standard is to be revised:
> <Essential Requirements Jan3107>
>
> If you take a look at this document you'll realize that complying with
> it is a time consuming and costly proposition for all the stakeholders
> which would include, at a minimum, all of the major commercial and open
> source implementors of common lisp.
having been involved in what I think was the last round of
CL-standards-related activity (which merely voted to reaffirm the
existing standard) I can agree with this from first-hand experience.
Any attempt to do anything more than reaffirm the existing standard
would almost certainly result in an enormously drawn-out saga with
various different parties trying to put forward more-or-less radical
changes to the language. This itself would be extremely expensive: if a
new standard was eventually agreed which differed substantially from
the existing one, then there would be a further, slightly hidden but
probably even more substantial, expense imposed on all existing
implementors.
My guess is that the sums involved would be millions of dollars: how
many millions I don't know. Languages like Java can afford this (but
note: Sun have made significant attempts to prevent formal
standardisation of Java, one of the reasons being the hideous expense).
Many other more fashionable languages finesse this by having either
only one implementation (Perl) or a "standard" which is defined by the
behaviour canonical implementation (Python). Even in the simplest,
single-implementation case, consider how much Perl 6 must have cost so
far.
>
>> All we need is a
>> small group of good developers who can informally undertake this
>> project.
>
> Then all you would end up with is an informal document that no one
> would be required to implement or adhere to if they wanted to call
> their implementation "ANSI Common Lisp." Since no one would be required
> to implement it or adhere to it, it would not be a standard.
And further: it *still* would cost a lot of money: what does a decent
developer cost per day?
--tim
On Mar 17, 7:41 am, ·············@gmail.com" <············@gmail.com>
wrote:
> small group of good developers who can informally undertake this
If it's informal, it's not a revision of the ANSI standard.
Regards,
Joel
+ ·············@gmail.com" <············@gmail.com>:
| It is 13 years since the CL ANSI standard and still it hasn't been
| revised. Are there any specific plans for it? Isn't this acting as a
| hampering point in such a cool programming language?
If you search back in time you will find that this question has been
discussed to death in this newsgroup. And frankly, we're all (well,
most of us) sick and tired of the subject. We just want to get on
with using the language.
In summary, yes it's been 13 years, no, it hasn't been revised, and no,
there are no specific plans to revise it. Partly because the process
of revising an ANSI standard is hugely expensive, and there are no big
players with the kind of money to throw at it.
As to the hampering bit, a lot of activity in recent times seems to
indicate that people don't feel too hampered. Seriously, does Kenny
look hampered to you?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
············@gmail.com wrote:
> It is 13 years since the CL ANSI standard and still it hasn't been
> revised. Are there any specific plans for it? Isn't this acting as a
> hampering point in such a cool programming language?
As others have already pointed out, a standardization process like ANSI
incurs too much overhead at this stage. If at all, a light-weight
process is needed.
We have set up the "Common Lisp Document Repository" as a possible
answer, and it seems to have made a good start so far. See
http://cdr.eurolisp.org for more details.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
(message (Hello 'Pascal)
(you :wrote :on '(Sat, 17 Mar 2007 13:07:31 +0100))
(
PC> We have set up the "Common Lisp Document Repository" as a possible
PC> answer, and it seems to have made a good start so far. See
PC> http://cdr.eurolisp.org for more details.
there is also CLRFI http://clrfi.alu.org/
but i see it's not very popular :)
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"?? ???? ??????? ?????")
On Mar 16, 2:42 pm, ·············@gmail.com" <············@gmail.com>
wrote:
> It is 13 years since the CL ANSI standard and still it hasn't been
> revised. Are there any specific plans for it? Isn't this acting as a
> hampering point in such a cool programming language?
As you've already seen in other replies, the general conclusion is
that there is no immediate need for a spec update, and the costs of
doing so would be extreme in any case. I would tend to agree, at
least at the moment.
Of more immediate interest from the standpoint of practicality is the
status of the Draft specification document which is publicly available
in TeX form (this could be used to create, in theory, an unofficial
document which might attempt to gain a following through force of
merit, and more practically as a great way to document existing lisp
implementations) but after looking into that situation my reluctant
conclusion is that it is even more hopeless than the official spec in
a strict legal sense. There have been many discussions on the subject
which hopefully will give a pretty good overview of the situation.
The links I'm aware of are:
http://groups.google.co.uk/group/comp.lang.lisp/msg/5828f58fa34e2ce8
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/5f105c469acd00fe/358de00dcbdc5e74?lnk=gst&q=ANSI&rnum=1#358de00dcbdc5e74
Some related threads on the Gardeners list:
·····································@lispniks.com/msg00134.html
·····································@lispniks.com/msg01531.html
This thread pertains to the CLRFI effort:
·····································@lispniks.com/msg00884.html
And the Hyperspec:
·····································@lispniks.com/msg00175.html
On Mar 16, 11:42 am, ·············@gmail.com" <············@gmail.com>
wrote:
> It is 13 years since the CL ANSI standard and still it hasn't been
> revised. Are there any specific plans for it? Isn't this acting as a
> hampering point in such a cool programming language?
No, I am. I eviscerate dullards like you here on c.l.lisp and then big
corporations abandon plans to switch to Lisp.
hth,kzo
On Mar 19, 2:05 pm, ·········@gmail.com wrote:
> On Mar 16, 11:42 am, ·············@gmail.com" <············@gmail.com>
> wrote:
>
> > It is 13 years since the CL ANSI standard and still it hasn't been
> > revised. Are there any specific plans for it? Isn't this acting as a
> > hampering point in such a cool programming language?
>
> No, I am. I eviscerate dullards like you here on c.l.lisp and then big
> corporations abandon plans to switch to Lisp.
>
> hth,kzo
I dont want to start flamming but your point is irrelevant
On Mar 19, 11:42 pm, ·············@gmail.com" <············@gmail.com>
wrote:
> On Mar 19, 2:05 pm, ·········@gmail.com wrote:
>
> > On Mar 16, 11:42 am, ·············@gmail.com" <············@gmail.com>
> > wrote:
>
> > > It is 13 years since the CL ANSI standard and still it hasn't been
> > > revised. Are there any specific plans for it? Isn't this acting as a
> > > hampering point in such a cool programming language?
>
> > No, I am. I eviscerate dullards like you here on c.l.lisp and then big
> > corporations abandon plans to switch to Lisp.
>
> > hth,kzo
>
> I dont want to start flamming but your point is irrelevant
Ah, great, it has been a while since we had a continuing non-
continuation.
Not relevant to you, but then you are a dullard, so you missed the
point I was making. Others have already explained the ignorance of
your question, especially the fallacious leap from unchanged to needs
change. You look at languages like Python and Java that are changing
every day to become more like Lisp, and then wonder why Lisp is not
changing to become more like Lisp. Ka-ching! Then you take this sloppy
thinking public -- in a group for Lisp enthusiasts -- and whine about /
me/ starting a flamewar. Hell, you are even daft enough to email me
directly, an e-Hit-Me-Sign if there ever was one.
I'll keep reading this thread, maybe you will (or already have) just
say, oh, right, silly question, my bad. (Yes, I am an insane
optimist.)
kt
On Mar 20, 8:01 am, ·········@gmail.com wrote:
> Ah, great, it has been a while since we had a continuing non-
> continuation.
Better than a non-continuing continuation, at least. Maybe I should
cross-post this to c.l.scheme?
·········@gmail.com wrote:
> On Mar 19, 11:42 pm, ·············@gmail.com" <············@gmail.com>
> wrote:
>> On Mar 19, 2:05 pm, ·········@gmail.com wrote:
>>
>>> On Mar 16, 11:42 am, ·············@gmail.com" <············@gmail.com>
>>> wrote:
>>>> It is 13 years since the CL ANSI standard and still it hasn't been
>>>> revised. Are there any specific plans for it? Isn't this acting as a
>>>> hampering point in such a cool programming language?
>>> No, I am. I eviscerate dullards like you here on c.l.lisp and then big
>>> corporations abandon plans to switch to Lisp.
>>> hth,kzo
>> I dont want to start flamming but your point is irrelevant
>
> Ah, great, it has been a while since we had a continuing non-
> continuation.
>
> Not relevant to you, but then you are a dullard, so you missed the
> point I was making. Others have already explained the ignorance of
> your question, especially the fallacious leap from unchanged to needs
> change. You look at languages like Python and Java that are changing
> every day to become more like Lisp, and then wonder why Lisp is not
> changing to become more like Lisp. Ka-ching! Then you take this sloppy
> thinking public -- in a group for Lisp enthusiasts -- and whine about /
> me/ starting a flamewar. Hell, you are even daft enough to email me
> directly, an e-Hit-Me-Sign if there ever was one.
>
> I'll keep reading this thread, maybe you will (or already have) just
> say, oh, right, silly question, my bad. (Yes, I am an insane
> optimist.)
>
> kt
>
Tough crowd.
I happened to be reading a relevant blog entry at findinglisp.com
(http://www.findinglisp.com/blog/2005/06/ilc-2005-wednesday-report-late.html)
on this topic just the other day. Notes on the proceedings at ILC 2005.
No fewer than three Lisp notables (Patrick Dussud, Henry Baker, and
John McCarthy) said Lisp needed to evolve. I especially found this
quote to be relevant to the OP's question:
"Finally, Baker suggested that Lisp has currently turned into a static
language and that static languages are doomed to death (like Latin, as
he put it). He said that Common Lisp has actually been a stumbling block
for further Lisp evolution as it has halted almost all innovation within
the Lisp community"
Mike
On 2007-03-24 13:14:37 -0400, Mike Ajemian <············@verizon.net> said:
> "Finally, Baker suggested that Lisp has currently turned into a static
> language and that static languages are doomed to death (like Latin, as
> he put it). He said that Common Lisp has actually been a stumbling
> block for further Lisp evolution as it has halted almost all innovation
> within the Lisp community"
fwiw (possibly not much) I personally think that the future evolution
of lisp is to be seen in the srfi process, and the gradual hammering
out of the r6rs standard. I think that the balance between a language
standard (here, r6rs) and evolvability/extensibility is something that
scheme has gotten right, and that common lisp has gotten wrong. This
may sound like common lisp treason - ;^) - but I think that the only
thing that has been keeping many common lispers using lisp is the large
body of functionality that is guaranteed available across
implementations. With r6rs and a key set of srfis this distinction will
no longer exist for practical purposes.
While common lisp has largely stagnated as a language (note - not as a
set of libraries, but as a language), scheme has continued to be
refined and periodically re-standardized. Scheme is adding
have-your-cake-and-it-it-too macros (srfi 72 which allows common lisp
style macros that are hygenic by default, but allow for identifier
capture when you want it), and a raft of other key functionality that
used to vary with each scheme implementation, but is now standardized
by srfis, functionality that in many cases was formerly only standard
in common lisp.
When there exist a handful of r6rs compliant scheme implementations,
each of which supports a large number of key srfis, scheme will in
effect be no different than common lisp with regard to the size and
power of its standard library of functionality. Moreover, scheme will
have a *standardized* path forward - a process that is known to work
that allows for periodic re-standardization (something that common lisp
still lacks), and a process that allows new functionality to be added
to the language in a standardized, community evaluated way. When the
day of r6rs + umpteen srfis arrives (and it is coming) I think that for
all but legacy common lisp code (which may be a significant
consideration for some) many common lispers will move to r6rs scheme
with a core set of commonly available srfis.
Until that time however, I still think that common lisp is more usable
today. Unfortunately, I think that the advantage that common lisp now
holds will be short lived, as common lisp is about to be lapped by r6rs
scheme and the srfi process.
Raffael Cavallaro wrote:
> On 2007-03-24 13:14:37 -0400, Mike Ajemian <············@verizon.net> said:
>
>> "Finally, Baker suggested that Lisp has currently turned into a static
>> language and that static languages are doomed to death (like Latin, as
>> he put it). He said that Common Lisp has actually been a stumbling
>> block for further Lisp evolution as it has halted almost all
>> innovation within the Lisp community"
>
> fwiw (possibly not much) I personally think that the future evolution of
> lisp is to be seen in the srfi process, and the gradual hammering out of
> the r6rs standard. I think that the balance between a language standard
> (here, r6rs) and evolvability/extensibility is something that scheme has
> gotten right, and that common lisp has gotten wrong. This may sound like
> common lisp treason - ;^) - but I think that the only thing that has
> been keeping many common lispers using lisp is the large body of
> functionality that is guaranteed available across implementations. With
> r6rs and a key set of srfis this distinction will no longer exist for
> practical purposes.
Last time I checked, there existed about at least 8-10 implementation of
ANSI Common Lisp. I guess it will take a considerable amount of time
until such a number of R6RS implementations will exist. From what I have
read in discussions in the R6RS mailing list, there is still also the
chance that many Scheme implementations will ignore R6RS for various
reasons.
It is also the case that the focus of ANSI Common Lisp and R6RS Scheme
is considerably different. For example in R6RS, no object system is
included. So it's not the case that "just" because R6RS is a
considerably larger specification than R5RS that many Common Lispers
will just switch to Scheme.
It's true that SRFI is a good idea, though.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2007-03-24 20:47:27 -0400, Pascal Costanza <··@p-cos.net> said:
> Last time I checked, there existed about at least 8-10 implementation
> of ANSI Common Lisp. I guess it will take a considerable amount of time
> until such a number of R6RS implementations will exist.
Agreed - which is why I still use common lisp.
> From what I have read in discussions in the R6RS mailing list, there
> is still also the chance that many Scheme implementations will ignore
> R6RS for various reasons.
I think that having a number of implementations that provide a
subtantial group of srfis is more important than r6rs itself.
>
> It is also the case that the focus of ANSI Common Lisp and R6RS Scheme
> is considerably different. For example in R6RS, no object system is
> included. So it's not the case that "just" because R6RS is a
> considerably larger specification than R5RS that many Common Lispers
> will just switch to Scheme.
Again, I think it's the fact that even r5rs + numerous srfis is a much
larger spec than simply r5rs that will begin to draw people to scheme.
The future existence of several high quality r6rs implementations will
just make it that much more compelling. To take your example, a
clos-alike is just an srfi away. It's really the *process* that gives
scheme a brighter future - there's a way for the community to come
together to propose and discuss extensions and modifications in a way
that puts the onus on implementors to make sure these things work once
the community process has spoken.
>
> It's true that SRFI is a good idea, though.
I think that if nothing that works as well comes along for common lisp,
the scheme srfi system will eventually swallow common lisp whole.
Raffael Cavallaro wrote:
>> It's true that SRFI is a good idea, though.
>
> I think that if nothing that works as well comes along for common lisp,
> the scheme srfi system will eventually swallow common lisp whole.
I hope that CDR can be for Common Lisp what SRFI is for Scheme. So far,
CDR had a good start - see http://cdr.eurolisp.org
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2007-03-25 04:25:22 -0400, Pascal Costanza <··@p-cos.net> said:
> I hope that CDR can be for Common Lisp what SRFI is for Scheme. So far,
> CDR had a good start - see http://cdr.eurolisp.org
I think the key thing is to get all the implementors on board. If you
don't have a committment from implementors that they will actually
implement any extension that is approved by some common lisp community
process, then it's unlikely to amount to much. This is what makes the
srfi process work imho - you have strong community pressure on
implementors to at least make sure that the reference implementations
of core srfis run properly.
Raffael Cavallaro wrote:
> On 2007-03-25 04:25:22 -0400, Pascal Costanza <··@p-cos.net> said:
>
>> I hope that CDR can be for Common Lisp what SRFI is for Scheme. So
>> far, CDR had a good start - see http://cdr.eurolisp.org
>
> I think the key thing is to get all the implementors on board.
Maybe not all of them, but a few major ones would be good, of course. We
are still working on this.
> If you
> don't have a committment from implementors that they will actually
> implement any extension that is approved by some common lisp community
> process, then it's unlikely to amount to much. This is what makes the
> srfi process work imho - you have strong community pressure on
> implementors to at least make sure that the reference implementations of
> core srfis run properly.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2007-03-26 03:33:30 -0400, Pascal Costanza <··@p-cos.net> said:
> Maybe not all of them, but a few major ones would be good, of course.
> We are still working on this.
Best of luck with this. Maybe a petition from common lisp users would
be helpful in forming a binding community process like the scheme srfi?
On Mar 24, 11:27 pm, Raffael Cavallaro <················@pas-d'espam-
s'il-vous-plait-mac.com>
>
> fwiw (possibly not much) I personally think that the future evolution
> of lisp is to be seen in the srfi process, and the gradual hammering
> out of the r6rs standard.
I'm not sure if I agree with what you say in the followups to this,
but I think that the approach of lots of mildly formal RFCs, almost
all of which standardise existing implementations, has been proved to
be just astonishingly successful: it is how IP and almost all its
application-layer were standardised for instance.
--tim
(And of course the CL spec was very largely standardising existing
implementations: I can't think of anything in the spec which I didn't
use implementations of before the spec came out (possibly the
condition system, but only because I didn't have very good access to a
Symbolics box.)
On 2007-03-29 06:57:27 -0400, "Tim Bradshaw" <··········@tfeb.org> said:
> I'm not sure if I agree with what you say in the followups to this,
> but I think that the approach of lots of mildly formal RFCs, almost
> all of which standardise existing implementations, has been proved to
> be just astonishingly successful: it is how IP and almost all its
> application-layer were standardised for instance.
No doubt your are right about this. For my part, I don't particularly
care whether the progress of common lisp takes the form of a set of
rfcs or a revivification of the existing clrfi process.
I do believe quite strongly that for any such process to succeed it
would require a core set of implementors to make some sort of
commitment to implementing community approved rfcs or clrfis. Absent
that commitment from implementors, we simply devolve to the current
state where library writers can do much portably, but some innovative
things that would require implementation support (such as a standard
means of environment access) are simply beyond our ability to implement
truly portably.
On 2007-03-24 17:14:37 +0000, Mike Ajemian <············@verizon.net> said:
> No fewer than three Lisp notables (Patrick Dussud, Henry Baker, and
> John McCarthy) said Lisp needed to evolve.
A new CL standard is not the way to evolve.
Tim Bradshaw wrote:
> On 2007-03-24 17:14:37 +0000, Mike Ajemian <············@verizon.net> said:
>
>> No fewer than three Lisp notables (Patrick Dussud, Henry Baker, and
>> John McCarthy) said Lisp needed to evolve.
>
> A new CL standard is not the way to evolve.
>
It is one way of n to evolve. Legal benefits. Lots of threads on this
over the years. There's a good page of info on the ALU Wiki about the
legal issues regarding evolving the language.
http://wiki.alu.org/Project_FreeSpec
On 2007-03-24 19:26:31 +0000, Mike Ajemian <············@verizon.net> said:
> It is one way of n to evolve.
But a shit way. Standards are sometimes a good way of standardising
existing practice. They are very, very seldom a good way of evolving a
language.
> There's a good page of info on the ALU Wiki about the legal issues
> regarding evolving the language.
Your standards of "good" are a bit lower than mine.
On 2007-03-24 20:57:06 +0000, Tim Bradshaw <···@tfeb.org> said:
> Standards are sometimes a good way of standardising existing practice.
> They are very, very seldom a good way of evolving a language.
In particular what many people do is confuse cause and effect here. A
standard is an effect, not a cause. If you want to improve the
language then what you do is, well, improve the language. At some
point agreement may be reached on the improvements and perhaps a
standard is the result. What you *don't* do if you want to improve the
language is write a new standard. Even less do you do what many cll
people seem to enjoy: ask someone *else* to write a new standard.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> In particular what many people do is confuse cause and effect here.
> A standard is an effect, not a cause. If you want to improve the
> language then what you do is, well, improve the language. At some
> point agreement may be reached on the improvements and perhaps a
> standard is the result. What you *don't* do if you want to improve
> the language is write a new standard. Even less do you do what many
> cll people seem to enjoy: ask someone *else* to write a new
> standard.
The "put up or shut up" argument is unrealistic.
* Unless there's some consensus around a process that is to carry the
standard forward, an implementor is liable and even justified to
reject any prospective change to their implementation as in danger
of being incompatible with a possible future standard.
* In the absence of any recognized process for carrying the standard
forward, it's unclear what the ground rules are for proposing
changes to the language. Even useful supplements to the existing
language might end up being incompatible with some
implementation-defined aspects of extant implementations. Are
improvements allowed to break existing conforming but non-portable
code, or de facto portable but non-conforming code? Could such
breakages be permitted, but only if big global switches are included
to allow implementations to continue providing their existing
interfaces?
* It's not even clear how to get the sort of improvements that belong
in a language specification out to the community in the absence of a
process for a future standard. Some interfaces can be left to
portable libraries, but things like FFIs, certain aspects of
networking, and threads can't. Implementors already provide
implementation-dependent extensions for some these sorts of things,
and probably have little incentive to adopt any particular
pre-standard interfaces, especially any interfaces that are
incompatible with what they're already doing.
So I think there needs to be some process, or at least a sense of the
possibilities for future directions for the common language, over and
above what any particular implementors might provide.
--
RmK
On 2007-03-26 18:46:21 +0100, Richard M Kreuter <·······@progn.net> said:
>
> The "put up or shut up" argument is unrealistic.
I disagree.
> Some interfaces can be left to
> portable libraries, but things like FFIs, certain aspects of
> networking, and threads can't.
Ah, the classic argument beloved of computer scientists everywhere:
`because some things are intractable, we should give up'. Perhaps
there are other things that are *not* intractable? Today's example:
the package system. We all know how much it sucks; we've all heard the
jokes about the chapter number. Well, let's carefully avoid the
one-bit mind answer and consider that may be it could be made better.
I dunno: a hierarchical package namespace borrowing from Java, and
maybe packages which extend others and a few other hacks. There's at
least one half-decent implementation of most of this out there that
relies only on tiny hooks in the Lisp implementation and runs on at
least three (four counting CMUCL and SBCL as distinct) major
implementations. So take that, clean it up, write documentation which
isn't just "look at what the code does", write a test suite, and you've
achieved something. In particular: you've solved the problem as it
affects you in a way which is every bit as good as a new standard.
> Implementors already provide
> implementation-dependent extensions for some these sorts of things,
> and probably have little incentive to adopt any particular
> pre-standard interfaces, especially any interfaces that are
> incompatible with what they're already doing.
Another standard argument. First of all, why not think about the users?
They'll use your stuff because it helps them write portable code which
saves them money. Implementors will use your stuff so users can port
more easily and because the existence of public documentation and a
reference implementation with test suite both save them money.
I no longer have the time or energy to argue about this - this thread
is doing a good job of reminding me why I no longer program in Lisp.
It's like washing with coarse sandpaper.
On Mon, 26 Mar 2007 19:50:47 +0100, Tim Bradshaw <···@tfeb.org> wrote:
> I no longer have the time or energy to argue about this - this
> thread is doing a good job of reminding me why I no longer program
> in Lisp.
Because you need the spare time for c.l.l?
:)
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On 2007-03-26 19:58:06 +0100, Edi Weitz <········@agharta.de> said:
> Because you need the spare time for c.l.l?
Pretty much: I figure I ought to be able to cause at least a few deaths
a year by inducing apoplexy and that justifies my existence.
It just occurred to me that one rather successful standards body, the
IETF, has as their motto: "rough consensus and working code".
In other words, to carry weight in the IETF community you need to
demonstrate your ideas to some level, talking about what others should
be doing is not the easy road to internet famedom.
I am not saying that IETF processes are above reproach but I would
consider the internet as a pretty big success none the less. And this
is even a grassroots standards body; no goverment big-wicks are in
control there.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
On Mar 26, 8:50 pm, Christian Lynbech <·········@defun.dk> wrote:
> It just occurred to me that one rather successful standards body, the
> IETF, has as their motto: "rough consensus and working code".
>
> In other words, to carry weight in the IETF community you need to
> demonstrate your ideas to some level, talking about what others should
> be doing is not the easy road to internet famedom.
>
> I am not saying that IETF processes are above reproach but I would
> consider the internet as a pretty big success none the less. And this
> is even a grassroots standards body; no goverment big-wicks are in
> control there.
>
I wish I had written this article: it's exactly right in every
respect. Thanks!
-tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> On Mar 26, 8:50 pm, Christian Lynbech <·········@defun.dk> wrote:
> > It just occurred to me that one rather successful standards body, the
> > IETF, has as their motto: "rough consensus and working code".
> >
> > In other words, to carry weight in the IETF community you need to
> > demonstrate your ideas to some level, talking about what others should
> > be doing is not the easy road to internet famedom.
> >
> > I am not saying that IETF processes are above reproach but I would
> > consider the internet as a pretty big success none the less. And this
> > is even a grassroots standards body; no goverment big-wicks are in
> > control there.
> >
>
> I wish I had written this article: it's exactly right in every
> respect. Thanks!
>
Adding to that, ISO might endorse the Office Open XML standard,
loosing all credibility in the process.
In article <·····················@news.demon.co.uk>,
Tim Bradshaw <···@tfeb.org> wrote:
> On 2007-03-26 18:46:21 +0100, Richard M Kreuter <·······@progn.net> said:
>
> >
> > The "put up or shut up" argument is unrealistic.
>
> I disagree.
>
> > Some interfaces can be left to
> > portable libraries, but things like FFIs, certain aspects of
> > networking, and threads can't.
>
> Ah, the classic argument beloved of computer scientists everywhere:
> `because some things are intractable, we should give up'. Perhaps
> there are other things that are *not* intractable? Today's example:
> the package system. We all know how much it sucks; we've all heard the
> jokes about the chapter number. Well, let's carefully avoid the
> one-bit mind answer and consider that may be it could be made better.
> I dunno: a hierarchical package namespace borrowing from Java, and
> maybe packages which extend others and a few other hacks. There's at
> least one half-decent implementation of most of this out there that
> relies only on tiny hooks in the Lisp implementation and runs on at
> least three (four counting CMUCL and SBCL as distinct) major
> implementations. So take that, clean it up, write documentation which
> isn't just "look at what the code does", write a test suite, and you've
> achieved something. In particular: you've solved the problem as it
> affects you in a way which is every bit as good as a new standard.
>
> > Implementors already provide
> > implementation-dependent extensions for some these sorts of things,
> > and probably have little incentive to adopt any particular
> > pre-standard interfaces, especially any interfaces that are
> > incompatible with what they're already doing.
>
> Another standard argument. First of all, why not think about the users?
> They'll use your stuff because it helps them write portable code which
> saves them money. Implementors will use your stuff so users can port
> more easily and because the existence of public documentation and a
> reference implementation with test suite both save them money.
>
> I no longer have the time or energy to argue about this - this thread
> is doing a good job of reminding me why I no longer program in Lisp.
Is it because
a) you have decided to invest your time in Usenet discussions instead?
b) you are an old frustrated (ex-) Lisp developer?
c) you are frustrated by educating Lisp newbies since 40 years?
d) Java jobs are better paid and easier to find?
e) you don't program anymore?
f) Common Lisp is so ugly?
g) you are waiting for Arc to be released?
h) Java programming is more fun?
i) Haskell programming is more fun?
j) Python programming is more fun?
k) of something else?
> It's like washing with coarse sandpaper.
--
http://lispm.dyndns.org
On 2007-03-26 22:09:02 +0100, Rainer Joswig <······@lisp.de> said:
> a) you have decided to invest your time in Usenet discussions instead?
the `maybe I can make them go away / die' hope is always there, though
I realise that WMD is a better option (and I bought a bunch off that
Saddam guy).
> b) you are an old frustrated (ex-) Lisp developer?
> c) you are frustrated by educating Lisp newbies since 40 years?
> d) Java jobs are better paid and easier to find?
Never looked
> e) you don't program anymore?
Mostly this one, yes
> f) Common Lisp is so ugly?
> g) you are waiting for Arc to be released?
Definitely not
> h) Java programming is more fun?
> i) Haskell programming is more fun?
> j) Python programming is more fun?
Python, ick.
> k) of something else?
Tim Bradshaw <···@tfeb.org> writes:
> Today's example: the package system. We all know how much it sucks;
> we've all heard the jokes about the chapter number.
We do and we have? Is there a reference URL or citation for this
universally-accepted axiom?
> Well, let's carefully avoid the one-bit mind answer and consider that
> may be it could be made better.
I agree that there are definitely places where incremental improvements
may be made. But going from that to "we all agree it sucks" is a large
step.
One of the reasons I use Lisp rather than Java for certain tasks is
specifically the way symbols and packages are handled in Lisp,
particularly regarding inherited CLOS slot and method names.
--
vsync
http://quadium.net/~vsync/
Every answer asks a more beautiful question.
-- http://www.cyberciti.biz/faq/
On Mar 28, 12:28 am, Tim Howe <····@quadium.net> wrote:
>
> We do and we have? Is there a reference URL or citation for this
> universally-accepted axiom?
Probably not. Go look up the chapter numbers in cltl2 and the spec:
I'm fairly sure they were chosen deliberately (remember the authors
were mostly from the US).
> I agree that there are definitely places where incremental improvements
> may be made. But going from that to "we all agree it sucks" is a large
> step.
What I was trying to say was that despite the common knowledge it
actually turns out to suck less than you might think, and various
really quite significant improvements can be made with little or no
support from the underlying system that is not already there. (In the
case of packages & the improvements I am talking about, the underlying
support would be a standard hook in the string->package conversion and
an undertaking that it is always called.)
And the meta point is that there are many other places where this is
true.
--tim
Tim Bradshaw wrote:
> On 2007-03-24 19:26:31 +0000, Mike Ajemian <············@verizon.net> said:
>
>> It is one way of n to evolve.
>
> But a shit way. Standards are sometimes a good way of standardising
> existing practice. They are very, very seldom a good way of evolving a
> language.
Like it or not, it's still a valid member of the set of all
possibilities. I've never been part of a standards process (I have been
part of an OS release "old school" and that was *tense*). From what
I've read of CLtL2, the standards process was a combination of
standardization with some evolution. I'd welcome correction on this point.
>> There's a good page of info on the ALU Wiki about the legal issues
>> regarding evolving the language.
>
>
> Your standards of "good" are a bit lower than mine.
>
My standards are so low, I'll even respond to you. The page described
some legal issues better than I could in the 2 minutes I had to reply.
I liked the fragmented, rambling tone - it really spoke to the
difficulty grokking how pervasive the legal issues are. Any time you'd
like to contribute your own link, feel free.
On 2007-03-24 23:25:48 +0000, Mike Ajemian <············@verizon.net> said:
> Like it or not, it's still a valid member of the set of all possibilities.
Breaking the Geheimschreiber by exhaustively enumerating all chi & psi
streams would have been "a valid member of the set of all
possibilities". Luckily we had smarter people.
Tim Bradshaw wrote:
> On 2007-03-24 23:25:48 +0000, Mike Ajemian <············@verizon.net> said:
>
>> Like it or not, it's still a valid member of the set of all
>> possibilities.
>
> Breaking the Geheimschreiber by exhaustively enumerating all chi & psi
> streams would have been "a valid member of the set of all
> possibilities". Luckily we had smarter people.
>
Yawn. You must be a riot at parties.
Mike Ajemian wrote:
> Tim Bradshaw wrote:
>
>> On 2007-03-24 23:25:48 +0000, Mike Ajemian <············@verizon.net>
>> said:
>>
>>> Like it or not, it's still a valid member of the set of all
>>> possibilities.
>>
>>
>> Breaking the Geheimschreiber by exhaustively enumerating all chi & psi
>> streams would have been "a valid member of the set of all
>> possibilities". Luckily we had smarter people.
>>
>
> Yawn. You must be a riot at parties.
And you must be the life of a funeral.
kenny
--
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
"Algebra is the metaphysics of arithmetic." - John Ray
http://www.theoryyalgebra.com/
Ken Tilton wrote:
>
>
> Mike Ajemian wrote:
>> Tim Bradshaw wrote:
>>
>>> On 2007-03-24 23:25:48 +0000, Mike Ajemian <············@verizon.net>
>>> said:
>>>
>>>> Like it or not, it's still a valid member of the set of all
>>>> possibilities.
>>>
>>>
>>> Breaking the Geheimschreiber by exhaustively enumerating all chi &
>>> psi streams would have been "a valid member of the set of all
>>> possibilities". Luckily we had smarter people.
>>>
>>
>> Yawn. You must be a riot at parties.
>
> And you must be the life of a funeral.
>
> kenny
>
Is that the best you got? I thought you'se a New Yorker? What gives?
You're slippin'. You move out of town, or somethin'?
Mike Ajemian wrote:
> Ken Tilton wrote:
>
>>
>>
>> Mike Ajemian wrote:
>>
>>> Tim Bradshaw wrote:
>>>
>>>> On 2007-03-24 23:25:48 +0000, Mike Ajemian
>>>> <············@verizon.net> said:
>>>>
>>>>> Like it or not, it's still a valid member of the set of all
>>>>> possibilities.
>>>>
>>>>
>>>>
>>>> Breaking the Geheimschreiber by exhaustively enumerating all chi &
>>>> psi streams would have been "a valid member of the set of all
>>>> possibilities". Luckily we had smarter people.
>>>>
>>>
>>> Yawn. You must be a riot at parties.
>>
>>
>> And you must be the life of a funeral.
>>
>> kenny
>>
>
> Is that the best you got? I thought you'se a New Yorker? What gives?
> You're slippin'. You move out of town, or somethin'?
Your personal flaming is so passe on comp.lang.lisp. Killfiles, however,
are not.
kt
--
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
"Algebra is the metaphysics of arithmetic." - John Ray
http://www.theoryyalgebra.com/
On Tue, 27 Mar 2007 15:23:43 GMT, Mike Ajemian <············@verizon.net> said:
| Ken Tilton wrote:
|| Mike Ajemian wrote:
||| Tim Bradshaw wrote:
|||
|||| On 2007-03-24 23:25:48 +0000, Mike Ajemian
|||| <············@verizon.net> said:
||||
||||| Like it or not, it's still a valid member of the set of all
||||| possibilities.
||||
||||
|||| Breaking the Geheimschreiber by exhaustively enumerating all chi &
|||| psi streams would have been "a valid member of the set of all
|||| possibilities". Luckily we had smarter people.
||||
|||
||| Yawn. You must be a riot at parties.
|| And you must be the life of a funeral.
|| kenny
||
| Is that the best you got? I thought you'se a New Yorker? What gives?
| You're slippin'. You move out of town, or somethin'?
You talkin' to who? What's your problem?
---Vassil.
--
The truly good code is the obviously correct code.
Vassil Nikolov wrote:
> On Tue, 27 Mar 2007 15:23:43 GMT, Mike Ajemian <············@verizon.net> said:
>
> | Ken Tilton wrote:
> || Mike Ajemian wrote:
> ||| Tim Bradshaw wrote:
> |||
> |||| On 2007-03-24 23:25:48 +0000, Mike Ajemian
> |||| <············@verizon.net> said:
> ||||
> ||||| Like it or not, it's still a valid member of the set of all
> ||||| possibilities.
> ||||
> ||||
> |||| Breaking the Geheimschreiber by exhaustively enumerating all chi &
> |||| psi streams would have been "a valid member of the set of all
> |||| possibilities". Luckily we had smarter people.
> ||||
> |||
> ||| Yawn. You must be a riot at parties.
> || And you must be the life of a funeral.
> || kenny
> ||
>
> | Is that the best you got? I thought you'se a New Yorker? What gives?
> | You're slippin'. You move out of town, or somethin'?
>
> You talkin' to who? What's your problem?
>
> ---Vassil.
>
The guy that chimed in with the funeral comment. Didn't think I had a
problem, just bantering with people who were more interested in
exchanging light-hearted insults than ideas. Figured the conversation
would get better...<shrug>. Oh well. Thanks for asking.
Mike
On Wed, 28 Mar 2007 06:11:42 GMT, Mike Ajemian <············@verizon.net> said:
| Vassil Nikolov wrote:
|| On Tue, 27 Mar 2007 15:23:43 GMT, Mike Ajemian <············@verizon.net> said:
|| | Ken Tilton wrote:
|| || Mike Ajemian wrote:
|| ||| Tim Bradshaw wrote:
|| ||| |||| On 2007-03-24 23:25:48 +0000, Mike Ajemian
|| |||| <············@verizon.net> said:
|| |||| ||||| Like it or not, it's still a valid member of the set of
|| all
|| ||||| possibilities.
|| |||| |||| |||| Breaking the Geheimschreiber by exhaustively
|| enumerating all chi &
|| |||| psi streams would have been "a valid member of the set of all
|| |||| possibilities". Luckily we had smarter people.
|| |||| ||| ||| Yawn. You must be a riot at parties.
|| || And you must be the life of a funeral.
|| || kenny
|| || | Is that the best you got? I thought you'se a New Yorker? What
|| gives?
|| | You're slippin'. You move out of town, or somethin'?
|| You talkin' to who? What's your problem?
|| ---Vassil.
||
| The guy that chimed in with the funeral comment. Didn't think I had a
| problem, just bantering with people who were more interested in
| exchanging light-hearted insults than ideas. Figured the conversation
| would get better...<shrug>. Oh well. Thanks for asking.
Well... I thought you'd recognize the expressions, which I think
have outlived their serious usage these days (just in my opinion).
Especially "you talkin' to me?" has been rather famous ever since
Robert De Niro spoke it in front of a mirror...
---Vassil.
--
The truly good code is the obviously correct code.
On 2007-03-28 06:13:40 -0400, Vassil Nikolov <···············@pobox.com> said:
> Well... I thought you'd recognize the expressions, which I think
> have outlived their serious usage these days (just in my opinion).
> Especially "you talkin' to me?" has been rather famous ever since
> Robert De Niro spoke it in front of a mirror...
Just a sanity check for you Vassil - some of us did get the Taxi
Driver/De Niro reference from your "You talkin' to who?" post.
Raffael Cavallaro wrote:
> On 2007-03-28 06:13:40 -0400, Vassil Nikolov <···············@pobox.com>
> said:
>
>> Well... I thought you'd recognize the expressions, which I think
>> have outlived their serious usage these days (just in my opinion).
>> Especially "you talkin' to me?" has been rather famous ever since
>> Robert De Niro spoke it in front of a mirror...
>
>
> Just a sanity check for you Vassil - some of us did get the Taxi
> Driver/De Niro reference from your "You talkin' to who?" post.
>
And my algera software plays that clip when you wake up the coach to ask
for a hint. Not part of the demo, I am afraid, but other clips are.
kt
--
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
"Algebra is the metaphysics of arithmetic." - John Ray
http://www.theoryyalgebra.com/
Vassil Nikolov wrote:
> On Wed, 28 Mar 2007 06:11:42 GMT, Mike Ajemian <············@verizon.net> said:
>
> | Vassil Nikolov wrote:
> || On Tue, 27 Mar 2007 15:23:43 GMT, Mike Ajemian <············@verizon.net> said:
> || | Ken Tilton wrote:
> || || Mike Ajemian wrote:
> || ||| Tim Bradshaw wrote:
> || ||| |||| On 2007-03-24 23:25:48 +0000, Mike Ajemian
> || |||| <············@verizon.net> said:
> || |||| ||||| Like it or not, it's still a valid member of the set of
> || all
> || ||||| possibilities.
> || |||| |||| |||| Breaking the Geheimschreiber by exhaustively
> || enumerating all chi &
> || |||| psi streams would have been "a valid member of the set of all
> || |||| possibilities". Luckily we had smarter people.
> || |||| ||| ||| Yawn. You must be a riot at parties.
> || || And you must be the life of a funeral.
> || || kenny
> || || | Is that the best you got? I thought you'se a New Yorker? What
> || gives?
> || | You're slippin'. You move out of town, or somethin'?
> || You talkin' to who? What's your problem?
> || ---Vassil.
> ||
>
> | The guy that chimed in with the funeral comment. Didn't think I had a
> | problem, just bantering with people who were more interested in
> | exchanging light-hearted insults than ideas. Figured the conversation
> | would get better...<shrug>. Oh well. Thanks for asking.
>
> Well... I thought you'd recognize the expressions, which I think
> have outlived their serious usage these days (just in my opinion).
> Especially "you talkin' to me?" has been rather famous ever since
> Robert De Niro spoke it in front of a mirror...
>
> ---Vassil.
>
>
<Smacking forehead in embarrassment>Right over my head...
On Mar 24, 7:25 pm, Mike Ajemian <············@verizon.net> wrote:
> >> There's a good page of info on the ALU Wiki about the legal issues
> >> regarding evolving the language.
>
> > Your standards of "good" are a bit lower than mine.
>
> My standards are so low, I'll even respond to you. The page described
> some legal issues better than I could in the 2 minutes I had to reply.
> I liked the fragmented, rambling tone - it really spoke to the
> difficulty grokking how pervasive the legal issues are. Any time you'd
> like to contribute your own link, feel free.
I'll second that request, not as an argument but as a serious request
- PLEASE post a better link. I readily admit the Freespec page is not
very good, and I would be very glad to know of something better that
could be linked to in place of that. Or heck, it's a wiki - someone
fix it up into something more useful than it is now.
On Mar 27, 7:41 pm, "C Y" <···········@yahoo.com> wrote:
> I'll second that request, not as an argument but as a serious request
> - PLEASE post a better link. I readily admit the Freespec page is not
> very good, and I would be very glad to know of something better that
> could be linked to in place of that. Or heck, it's a wiki - someone
> fix it up into something more useful than it is now.
If this was aimed at me: I don't have a better document (I could write
one, but to what end since I think I've made it fairly clear I think
the proximate way forward is not via a standards process), I just
thought that one was not good.
On Mar 29, 5:11 am, "Tim Bradshaw" <··········@tfeb.org> wrote:
> On Mar 27, 7:41 pm, "C Y" <···········@yahoo.com> wrote:
>
> > I'll second that request, not as an argument but as a serious request
> > - PLEASE post a better link. I readily admit the Freespec page is not
> > very good, and I would be very glad to know of something better that
> > could be linked to in place of that. Or heck, it's a wiki - someone
> > fix it up into something more useful than it is now.
>
> If this was aimed at me: I don't have a better document (I could write
> one, but to what end since I think I've made it fairly clear I think
> the proximate way forward is not via a standards process), I just
> thought that one was not good.
Fair enough. I think it's worth having a good page summarizing the
issues involved with the ANSI spec, since it keeps coming up so often,
but that certainly doesn't come under the heading "fun and exciting
work." I took a stab at improving it last night - if there are
concrete suggestions as to how to improve it enough make it "good
enough for a FAQ answer" I'd like to hear them. Based on what I heard
from a number of players it's not practical to clarify the copyright
status of dpANS3 but I would like to at least leave the issues well
documented in case someone else wants to try someday.
"C Y" <···········@yahoo.com> writes:
> On Mar 29, 5:11 am, "Tim Bradshaw" <··········@tfeb.org> wrote:
>> On Mar 27, 7:41 pm, "C Y" <···········@yahoo.com> wrote:
>>
>> > I'll second that request, not as an argument but as a serious request
>> > - PLEASE post a better link. I readily admit the Freespec page is not
>> > very good, and I would be very glad to know of something better that
>> > could be linked to in place of that. Or heck, it's a wiki - someone
>> > fix it up into something more useful than it is now.
>>
>> If this was aimed at me: I don't have a better document (I could write
>> one, but to what end since I think I've made it fairly clear I think
>> the proximate way forward is not via a standards process), I just
>> thought that one was not good.
>
> Fair enough. I think it's worth having a good page summarizing the
> issues involved with the ANSI spec, since it keeps coming up so often,
> but that certainly doesn't come under the heading "fun and exciting
> work." I took a stab at improving it last night - if there are
> concrete suggestions as to how to improve it enough make it "good
> enough for a FAQ answer" I'd like to hear them. Based on what I heard
> from a number of players it's not practical to clarify the copyright
> status of dpANS3 but I would like to at least leave the issues well
> documented in case someone else wants to try someday.
I'm leaving soon for Cambridge, so I don't know how responsive I'll be
after this posting but...
http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
Enjoy
--
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
On Mar 29, 2:50 pm, Duane Rettig <····@franz.com> wrote:
> I'm leaving soon for Cambridge, so I don't know how responsive I'll be
> after this posting but...
>
> http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
Excellent. Thanks! Added.
CY
Mike Ajemian wrote:
> Tim Bradshaw wrote:
>> On 2007-03-24 17:14:37 +0000, Mike Ajemian <············@verizon.net>
>> said:
>>
>>> No fewer than three Lisp notables (Patrick Dussud, Henry Baker, and
>>> John McCarthy) said Lisp needed to evolve.
>>
>> A new CL standard is not the way to evolve.
>
> It is one way of n to evolve.
Everyone who says that "X" should evolve actually means that "X" should
improve. Evolution doesn't guarantee improvement. An evolution could
actually mean that things get worse (or that they stagnate while
creating the illusion of movement).
Also, everyone who says that "X" should improve has different ideas what
an improvement could mean. Patrick Dussud more or less literally meant
that Lisp should be changed such that it is easier to implement on top
of Microsoft's .NET. I am absolutely certain that that's not the kind of
improvement that Baker and McCarthy had in mind.
So, in other words, asking for Common Lisp to evolve is a vacuous
request that requires concretion. Interestingly, for each concrete
suggestion that has been made in such discussions, actual projects led
by people who invest their precious time already exist.
So here is a concrete question: What are you missing?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Mike Ajemian wrote:
>> Tim Bradshaw wrote:
>>> On 2007-03-24 17:14:37 +0000, Mike Ajemian <············@verizon.net>
>>> said:
>>>
>>>> No fewer than three Lisp notables (Patrick Dussud, Henry Baker, and
>>>> John McCarthy) said Lisp needed to evolve.
>>>
>>> A new CL standard is not the way to evolve.
>>
>> It is one way of n to evolve.
>
> Everyone who says that "X" should evolve actually means that "X" should
> improve. Evolution doesn't guarantee improvement. An evolution could
> actually mean that things get worse (or that they stagnate while
> creating the illusion of movement).
>
> Also, everyone who says that "X" should improve has different ideas what
> an improvement could mean. Patrick Dussud more or less literally meant
> that Lisp should be changed such that it is easier to implement on top
> of Microsoft's .NET. I am absolutely certain that that's not the kind of
> improvement that Baker and McCarthy had in mind.
>
> So, in other words, asking for Common Lisp to evolve is a vacuous
> request that requires concretion. Interestingly, for each concrete
> suggestion that has been made in such discussions, actual projects led
> by people who invest their precious time already exist.
>
> So here is a concrete question: What are you missing?
>
>
> Pascal
>
If you want clarification of what evolve means, you may want to take it
up with the folks I quoted. It sounds like you're saying John McCarthy
is making vacuous requests by suggesting Lisp needs to evolve? I think
you misunderstood the reference.
The projects to which you refer are not standards. There is no recourse
if the project decides to change direction, alter interfaces or simply
shuts down. That doesn't diminish what different projects do or
provide, just highlights the risk inherent in using non-standard code.
In contrast, if your vendors' Lisp stops evolving, you can migrate your
Common Lisp code without modification to another distro.
I went searching and found the following (relevant) quote from Kent M.
Pitman:
"The whole reasons for standards is so that if you're a vendor and
tired of implementing the language, your customers can feel
comfortable going to someone else who implements the standard. Not
using a standard means convincing people to use an implementation they
can't "second source", which is bad. The key value of ANSI CL is not
that each and every technical decision is optimal, but rather that
each and every technical decision was agreed upon by the community to
be livable and something we would commonly support."
The thread containing the quote can be found at:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/a07ab00dd4330876/7bdcac6b7887b468?lnk=st&q=ansi+standard+lisp+update&rnum=1&hl=en#7bdcac6b7887b468
This is a difficult discussion to have. The standards process is one
for the vendors - they have to initiate and push it through. The
community supports the process, but ultimately, the implementation of
the standard is up to them. That's a huge commitment of time, energy
and money beyond just getting the standard written - to them it's
forever. So, under the heading, "Is this a private fight, or can
anybody join in?" I'm throwing in my hat. As a small token of support,
I'll commit to volunteer to help with the process (should a standards
process spontaneously erupt somewhere and I can be of assistance). I
can write and proofread docs, or when a standard is agreed upon, review
and test code. Or whatever.
Mike
Mike Ajemian wrote:
> Pascal Costanza wrote:
>> Mike Ajemian wrote:
>>> Tim Bradshaw wrote:
>>>> On 2007-03-24 17:14:37 +0000, Mike Ajemian
>>>> <············@verizon.net> said:
>>>>
>>>>> No fewer than three Lisp notables (Patrick Dussud, Henry Baker, and
>>>>> John McCarthy) said Lisp needed to evolve.
>>>>
>>>> A new CL standard is not the way to evolve.
>>>
>>> It is one way of n to evolve.
>>
>> Everyone who says that "X" should evolve actually means that "X"
>> should improve. Evolution doesn't guarantee improvement. An evolution
>> could actually mean that things get worse (or that they stagnate while
>> creating the illusion of movement).
>>
>> Also, everyone who says that "X" should improve has different ideas
>> what an improvement could mean. Patrick Dussud more or less literally
>> meant that Lisp should be changed such that it is easier to implement
>> on top of Microsoft's .NET. I am absolutely certain that that's not
>> the kind of improvement that Baker and McCarthy had in mind.
>>
>> So, in other words, asking for Common Lisp to evolve is a vacuous
>> request that requires concretion. Interestingly, for each concrete
>> suggestion that has been made in such discussions, actual projects led
>> by people who invest their precious time already exist.
>>
>> So here is a concrete question: What are you missing?
>>
>>
>> Pascal
>>
>
> If you want clarification of what evolve means, you may want to take it
> up with the folks I quoted. It sounds like you're saying John McCarthy
> is making vacuous requests by suggesting Lisp needs to evolve? I think
> you misunderstood the reference.
I have been present when he gave that talk. He specifically said
something to the effect that standardization of Common Lisp shouldn't
have started. He also said that if a bomb would be dropped on the
conference, more than half of the Lisp users would be gone, which would
be good because we could then start from scratch.
This all doesn't sound to me as a request for a revision of ANSI Common
Lisp.
John McCarthy (and Henry Baker) are scientist. For scientists, a
standard is not even remotely as important as for industrial users.
> So, under the heading, "Is this a private fight, or can
> anybody join in?" I'm throwing in my hat. As a small token of support,
> I'll commit to volunteer to help with the process (should a standards
> process spontaneously erupt somewhere and I can be of assistance). I
> can write and proofread docs, or when a standard is agreed upon, review
> and test code. Or whatever.
You're welcome to contribute to the Common Lisp Document Repository at
http://cdr.eurolisp.org - it had a good start, and for the foreseeable
future is, IMHO, the best we can get. [There is simply not enough money
in the Lisp community to start up a more heavy-weight process.]
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> [There is simply not enough money
> in the Lisp community to start up a more heavy-weight process.]
Of course there is. The limiting factor for change is not resources,
it's people like you who doggedly maintain that change is either
unnecessary or undesirable.
rg
Ron Garret wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> [There is simply not enough money
>> in the Lisp community to start up a more heavy-weight process.]
>
> Of course there is.
According to
http://groups.google.com/group/comp.lang.lisp/msg/15248a1b11c5a603 the
ANSI Common Lisp standardization took nearly 10 years and at least $400K.
If that's _not_ what you want to spend, you have to be more specific
than just saying "ANSI Common Lisp should be revised."
> The limiting factor for change is not resources,
> it's people like you who doggedly maintain that change is either
> unnecessary or undesirable.
No, that is not what I said. If you want to argue with yourself be my
guest, but if you want to debate me you will have to address what I
actually said, not what you would like to imagine that I said.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <···············@mid.individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> [There is simply not enough money
> >> in the Lisp community to start up a more heavy-weight process.]
> >
> > Of course there is.
>
> According to
> http://groups.google.com/group/comp.lang.lisp/msg/15248a1b11c5a603 the
> ANSI Common Lisp standardization took nearly 10 years and at least $400K.
>
> If that's _not_ what you want to spend, you have to be more specific
> than just saying "ANSI Common Lisp should be revised."
What *I* *want* to spend, and what is available, are not the same thing
(and both are distinct from what I might be willing to spend).
> > The limiting factor for change is not resources,
> > it's people like you who doggedly maintain that change is either
> > unnecessary or undesirable.
>
> No, that is not what I said.
You said "There is simply not enough money in the Lisp community to
start up a more heavy-weight process" implying (to me at least) that
resources are the limiting factor. They are not (or at least they need
not be).
rg
Ron Garret wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>> In article <···············@mid.individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>> [There is simply not enough money
>>>> in the Lisp community to start up a more heavy-weight process.]
>>> Of course there is.
>> According to
>> http://groups.google.com/group/comp.lang.lisp/msg/15248a1b11c5a603 the
>> ANSI Common Lisp standardization took nearly 10 years and at least $400K.
>>
>> If that's _not_ what you want to spend, you have to be more specific
>> than just saying "ANSI Common Lisp should be revised."
>
> What *I* *want* to spend, and what is available, are not the same thing
> (and both are distinct from what I might be willing to spend).
Of course, I didn't mean to imply that you would personally want to
spend $400K.
>>> The limiting factor for change is not resources,
>>> it's people like you who doggedly maintain that change is either
>>> unnecessary or undesirable.
>> No, that is not what I said.
>
> You said "There is simply not enough money in the Lisp community to
> start up a more heavy-weight process" implying (to me at least) that
> resources are the limiting factor. They are not (or at least they need
> not be).
Maybe, but I have never ever said that change is unnecessary or undesirable.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Mar 27, 4:44 pm, Mike Ajemian <············@verizon.net> wrote:
> I went searching and found the following (relevant) quote from Kent M.
> Pitman:
> [...]
However I'm fairly sure you'll also find KMP talking about how painful
the standards process was and about how there need to be much lighter-
weight ways of achieving this. I know he had an idea of `substandards'
which would help to achieve this, though I'm unsure if he posted stuff
about that or if it was just discussion around various meetings.
> As a small token of support,
> I'll commit to volunteer to help with the process (should a standards
> process spontaneously erupt somewhere and I can be of assistance). I
> can write and proofread docs, or when a standard is agreed upon, review
> and test code. Or whatever.
There is nothing to stop you becoming a member of X3J13 as far as I
know - I did. Of course it costs money, and considerably more money
if meetings happen.
--tim
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Evolution doesn't guarantee improvement.
Different is not necessarily better. But better is necessarily
different.
> An evolution could actually mean that things get worse
There is no reward without risk.
> So here is a concrete question: What are you missing?
http://www.python.org/doc/current/modindex.html
rg
Ron Garret wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>> So here is a concrete question: What are you missing?
>
> http://www.python.org/doc/current/modindex.html
Just out of curiosity. Are there a handful of modules from that list
that 1) you're particularly interested in, and 2) aren't provided by CL ?
>
> rg
In article <·················@bignews4.bellsouth.net>,
Brian Adkins <·················@gmail.com> wrote:
> Ron Garret wrote:
> > In article <···············@mid.individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >> So here is a concrete question: What are you missing?
> >
> > http://www.python.org/doc/current/modindex.html
>
> Just out of curiosity. Are there a handful of modules from that list
> that 1) you're particularly interested in, and 2) aren't provided by CL ?
That you would ask such a question indicates that you've missed the
point. I'm not talking about the modules, I'm talking about the *page*.
rg
On Tue, 27 Mar 2007 23:25:10 -0700, Ron Garret wrote:
> In article <·················@bignews4.bellsouth.net>,
> Brian Adkins <·················@gmail.com> wrote:
>
>> Ron Garret wrote:
>> > In article <···············@mid.individual.net>,
>> > Pascal Costanza <··@p-cos.net> wrote:
>> >> So here is a concrete question: What are you missing?
>> >
>> > http://www.python.org/doc/current/modindex.html
>>
>> Just out of curiosity. Are there a handful of modules from that list
>> that 1) you're particularly interested in, and 2) aren't provided by CL ?
>
> That you would ask such a question indicates that you've missed the
> point. I'm not talking about the modules, I'm talking about the *page*.
Yes, I certainly did miss your point. My bad - see when Pascal asked for
a concrete example of what was missing from Lisp to indicate it needed to
evolve, and you responded by posting a URL to a collection of Python
modules, I must have simply assumed you were referring to the
*content* of the page ;)
>
> rg
In article <······························@gmail.com>,
Brian Adkins <·················@gmail.com> wrote:
> On Tue, 27 Mar 2007 23:25:10 -0700, Ron Garret wrote:
>
> > In article <·················@bignews4.bellsouth.net>,
> > Brian Adkins <·················@gmail.com> wrote:
> >
> >> Ron Garret wrote:
> >> > In article <···············@mid.individual.net>,
> >> > Pascal Costanza <··@p-cos.net> wrote:
> >> >> So here is a concrete question: What are you missing?
> >> >
> >> > http://www.python.org/doc/current/modindex.html
> >>
> >> Just out of curiosity. Are there a handful of modules from that list
> >> that 1) you're particularly interested in, and 2) aren't provided by CL ?
> >
> > That you would ask such a question indicates that you've missed the
> > point. I'm not talking about the modules, I'm talking about the *page*.
>
> Yes, I certainly did miss your point. My bad - see when Pascal asked for
> a concrete example of what was missing from Lisp to indicate it needed to
> evolve, and you responded by posting a URL to a collection of Python
> modules, I must have simply assumed you were referring to the
> *content* of the page ;)
I *was* referring to the content of the page. The content of the page
is not modules. (The modules themselves are all built in to Python so
there is no need to visit a web page to obtain the modules if one is
using Python.)
The content of the page is POINTERS to DOCUMENTATION of the Python
STANDARD LIBRARY (with the "*standard* library" part being far and away
the most important of those three points for the purposes of this
discussion).
rg
On Wed, 28 Mar 2007 09:44:03 -0700, Ron Garret wrote:
> In article <······························@gmail.com>,
> Brian Adkins <·················@gmail.com> wrote:
>
>> On Tue, 27 Mar 2007 23:25:10 -0700, Ron Garret wrote:
>>
>> > In article <·················@bignews4.bellsouth.net>,
>> > Brian Adkins <·················@gmail.com> wrote:
>> >
>> >> Ron Garret wrote:
>> >> > In article <···············@mid.individual.net>,
>> >> > Pascal Costanza <··@p-cos.net> wrote:
>> >> >> So here is a concrete question: What are you missing?
>> >> >
>> >> > http://www.python.org/doc/current/modindex.html
>> >>
>> >> Just out of curiosity. Are there a handful of modules from that list
>> >> that 1) you're particularly interested in, and 2) aren't provided by CL ?
>> >
>> > That you would ask such a question indicates that you've missed the
>> > point. I'm not talking about the modules, I'm talking about the *page*.
>>
>> Yes, I certainly did miss your point. My bad - see when Pascal asked for
>> a concrete example of what was missing from Lisp to indicate it needed to
>> evolve, and you responded by posting a URL to a collection of Python
>> modules, I must have simply assumed you were referring to the
>> *content* of the page ;)
>
> I *was* referring to the content of the page. The content of the page
> is not modules. (The modules themselves are all built in to Python so
> there is no need to visit a web page to obtain the modules if one is
> using Python.)
>
> The content of the page is POINTERS to DOCUMENTATION of the Python
> STANDARD LIBRARY (with the "*standard* library" part being far and away
> the most important of those three points for the purposes of this
> discussion).
I thought CL stood for Common Lisp, not circumlocution...
Just spit it out Ron.
I asked, in effect, what aspects of the Python
standard library you felt were important and/or indicative of a lack in
CL, and you reply that it's not the modules but the *page*. So your grand
point in response to what CL needs to evolve is a better web page full of
pointers to library documentation. Sheesh...
>
> rg
In article <······························@gmail.com>,
Brian Adkins <·················@gmail.com> wrote:
> On Wed, 28 Mar 2007 09:44:03 -0700, Ron Garret wrote:
>
> > In article <······························@gmail.com>,
> > Brian Adkins <·················@gmail.com> wrote:
> >
> >> On Tue, 27 Mar 2007 23:25:10 -0700, Ron Garret wrote:
> >>
> >> > In article <·················@bignews4.bellsouth.net>,
> >> > Brian Adkins <·················@gmail.com> wrote:
> >> >
> >> >> Ron Garret wrote:
> >> >> > In article <···············@mid.individual.net>,
> >> >> > Pascal Costanza <··@p-cos.net> wrote:
> >> >> >> So here is a concrete question: What are you missing?
> >> >> >
> >> >> > http://www.python.org/doc/current/modindex.html
> >> >>
> >> >> Just out of curiosity. Are there a handful of modules from that list
> >> >> that 1) you're particularly interested in, and 2) aren't provided by CL
> >> >> ?
> >> >
> >> > That you would ask such a question indicates that you've missed the
> >> > point. I'm not talking about the modules, I'm talking about the *page*.
> >>
> >> Yes, I certainly did miss your point. My bad - see when Pascal asked for
> >> a concrete example of what was missing from Lisp to indicate it needed to
> >> evolve, and you responded by posting a URL to a collection of Python
> >> modules, I must have simply assumed you were referring to the
> >> *content* of the page ;)
> >
> > I *was* referring to the content of the page. The content of the page
> > is not modules. (The modules themselves are all built in to Python so
> > there is no need to visit a web page to obtain the modules if one is
> > using Python.)
> >
> > The content of the page is POINTERS to DOCUMENTATION of the Python
> > STANDARD LIBRARY (with the "*standard* library" part being far and away
> > the most important of those three points for the purposes of this
> > discussion).
>
> I thought CL stood for Common Lisp, not circumlocution...
>
> Just spit it out Ron.
Ptooey! ;-)
> I asked, in effect, what aspects of the Python
> standard library you felt were important and/or indicative of a lack in
> CL, and you reply that it's not the modules but the *page*. So your grand
> point in response to what CL needs to evolve is a better web page full of
> pointers to library documentation. Sheesh...
Almost. It needs a web page full of pointers to documentation of the
STANDARD library. And, of course, before that can be done there has to
first exist a standard library to document.
rg
Ron Garret wrote:
> Brian Adkins <·················@gmail.com> wrote:
>>>>>>> Pascal Costanza <··@p-cos.net> wrote:
>>>>>>>> So here is a concrete question: What are you missing?
>>>>>>> http://www.python.org/doc/current/modindex.html
...
>> I asked, in effect, what aspects of the Python
>> standard library you felt were important and/or indicative of a lack in
>> CL, and you reply that it's not the modules but the *page*. So your grand
>> point in response to what CL needs to evolve is a better web page full of
>> pointers to library documentation. Sheesh...
>
> Almost. It needs a web page full of pointers to documentation of the
> STANDARD library. And, of course, before that can be done there has to
> first exist a standard library to document.
IIRC, There's only one "distribution" of Python. The libraries you
linked to are "standard" in the sense that they are released with this
distribution. Thus, I could make a standard Lisp library by
distributing SBCL with some extra libraries, right? Or is there
something more to being a standard?
Yes, Lisp could do with better documentation and distribution of the
available libraries; it needs open user communities more than library
standards.
- DH
In article <································@comcast.com>,
D Herring <········@at.tentpost.dot.com> wrote:
> Ron Garret wrote:
> > Brian Adkins <·················@gmail.com> wrote:
> >>>>>>> Pascal Costanza <··@p-cos.net> wrote:
> >>>>>>>> So here is a concrete question: What are you missing?
> >>>>>>> http://www.python.org/doc/current/modindex.html
> ...
> >> I asked, in effect, what aspects of the Python
> >> standard library you felt were important and/or indicative of a lack in
> >> CL, and you reply that it's not the modules but the *page*. So your grand
> >> point in response to what CL needs to evolve is a better web page full of
> >> pointers to library documentation. Sheesh...
> >
> > Almost. It needs a web page full of pointers to documentation of the
> > STANDARD library. And, of course, before that can be done there has to
> > first exist a standard library to document.
>
> IIRC, There's only one "distribution" of Python.
No, there are at least three. There's the canonical distro, stackless
Python, and Jython. There may be others.
> The libraries you
> linked to are "standard" in the sense that they are released with this
> distribution. Thus, I could make a standard Lisp library by
> distributing SBCL with some extra libraries, right? Or is there
> something more to being a standard?
Yes: there has to be a community that agrees that what you say is the
standard is indeed the standard. (Note that the article "the" is
significant here. It is important that the community agree that it is
*the* standard, not *a* standard.)
> Yes, Lisp could do with better documentation and distribution of the
> available libraries; it needs open user communities more than library
> standards.
That depends on your quality metric.
rg
On Wed, 28 Mar 2007 19:35:11 -0700, Ron Garret wrote:
> In article <······························@gmail.com>,
> Brian Adkins <·················@gmail.com> wrote:
>
>> On Wed, 28 Mar 2007 09:44:03 -0700, Ron Garret wrote:
>>
>> > In article <······························@gmail.com>,
>> > Brian Adkins <·················@gmail.com> wrote:
>> >
>> >> On Tue, 27 Mar 2007 23:25:10 -0700, Ron Garret wrote:
>> >>
>> >> > In article <·················@bignews4.bellsouth.net>,
>> >> > Brian Adkins <·················@gmail.com> wrote:
>> >> >
>> >> >> Ron Garret wrote:
>> >> >> > In article <···············@mid.individual.net>,
>> >> >> > Pascal Costanza <··@p-cos.net> wrote:
>> >> >> >> So here is a concrete question: What are you missing?
>> >> >> >
>> >> >> > http://www.python.org/doc/current/modindex.html
>> >> >>
>> >> >> Just out of curiosity. Are there a handful of modules from that list
>> >> >> that 1) you're particularly interested in, and 2) aren't provided by CL
>> >> >> ?
>> >> >
>> >> > That you would ask such a question indicates that you've missed the
>> >> > point. I'm not talking about the modules, I'm talking about the *page*.
>> >>
>> >> Yes, I certainly did miss your point. My bad - see when Pascal asked for
>> >> a concrete example of what was missing from Lisp to indicate it needed to
>> >> evolve, and you responded by posting a URL to a collection of Python
>> >> modules, I must have simply assumed you were referring to the
>> >> *content* of the page ;)
>> >
>> > I *was* referring to the content of the page. The content of the page
>> > is not modules. (The modules themselves are all built in to Python so
>> > there is no need to visit a web page to obtain the modules if one is
>> > using Python.)
>> >
>> > The content of the page is POINTERS to DOCUMENTATION of the Python
>> > STANDARD LIBRARY (with the "*standard* library" part being far and away
>> > the most important of those three points for the purposes of this
>> > discussion).
>>
>> I thought CL stood for Common Lisp, not circumlocution...
>>
>> Just spit it out Ron.
>
> Ptooey! ;-)
>
>> I asked, in effect, what aspects of the Python
>> standard library you felt were important and/or indicative of a lack in
>> CL, and you reply that it's not the modules but the *page*. So your grand
>> point in response to what CL needs to evolve is a better web page full of
>> pointers to library documentation. Sheesh...
>
> Almost. It needs a web page full of pointers to documentation of the
> STANDARD library. And, of course, before that can be done there has to
> first exist a standard library to document.
Ah, the circumlocution comes full circle, so to speak. I guess we're back
to my original question regarding what functionality you feel is important
to include in a "standard" library that doesn't exist. Feel free to
re-read it; it's right above the part where you stated I was missing
the point. Care to take a stab at it now, or would you prefer to continue
spinning?
I'll tell you what; I'll start.
(setf cl-standard-library (cons "cl-ppcre" nil))
(push "clsql" cl-standard-library)
Poof - a standard library. Once it's complete, we can whip up a nifty web
page with pointers to documentation and stuff.
>
> rg
In article <······························@gmail.com>,
Brian Adkins <·················@gmail.com> wrote:
> On Wed, 28 Mar 2007 19:35:11 -0700, Ron Garret wrote:
>
> > In article <······························@gmail.com>,
> > Brian Adkins <·················@gmail.com> wrote:
> >
> >> On Wed, 28 Mar 2007 09:44:03 -0700, Ron Garret wrote:
> >>
> >> > In article <······························@gmail.com>,
> >> > Brian Adkins <·················@gmail.com> wrote:
> >> >
> >> >> On Tue, 27 Mar 2007 23:25:10 -0700, Ron Garret wrote:
> >> >>
> >> >> > In article <·················@bignews4.bellsouth.net>,
> >> >> > Brian Adkins <·················@gmail.com> wrote:
> >> >> >
> >> >> >> Ron Garret wrote:
> >> >> >> > In article <···············@mid.individual.net>,
> >> >> >> > Pascal Costanza <··@p-cos.net> wrote:
> >> >> >> >> So here is a concrete question: What are you missing?
> >> >> >> >
> >> >> >> > http://www.python.org/doc/current/modindex.html
> >> >> >>
> >> >> >> Just out of curiosity. Are there a handful of modules from that list
> >> >> >> that 1) you're particularly interested in, and 2) aren't provided by
> >> >> >> CL
> >> >> >> ?
> >> >> >
> >> >> > That you would ask such a question indicates that you've missed the
> >> >> > point. I'm not talking about the modules, I'm talking about the
> >> >> > *page*.
> >> >>
> >> >> Yes, I certainly did miss your point. My bad - see when Pascal asked
> >> >> for
> >> >> a concrete example of what was missing from Lisp to indicate it needed
> >> >> to
> >> >> evolve, and you responded by posting a URL to a collection of Python
> >> >> modules, I must have simply assumed you were referring to the
> >> >> *content* of the page ;)
> >> >
> >> > I *was* referring to the content of the page. The content of the page
> >> > is not modules. (The modules themselves are all built in to Python so
> >> > there is no need to visit a web page to obtain the modules if one is
> >> > using Python.)
> >> >
> >> > The content of the page is POINTERS to DOCUMENTATION of the Python
> >> > STANDARD LIBRARY (with the "*standard* library" part being far and away
> >> > the most important of those three points for the purposes of this
> >> > discussion).
> >>
> >> I thought CL stood for Common Lisp, not circumlocution...
> >>
> >> Just spit it out Ron.
> >
> > Ptooey! ;-)
> >
> >> I asked, in effect, what aspects of the Python
> >> standard library you felt were important and/or indicative of a lack in
> >> CL, and you reply that it's not the modules but the *page*. So your grand
> >> point in response to what CL needs to evolve is a better web page full of
> >> pointers to library documentation. Sheesh...
> >
> > Almost. It needs a web page full of pointers to documentation of the
> > STANDARD library. And, of course, before that can be done there has to
> > first exist a standard library to document.
>
> Ah, the circumlocution comes full circle, so to speak. I guess we're back
> to my original question regarding what functionality you feel is important
> to include in a "standard" library that doesn't exist.
And I will reiterate my original answer: the functionality that I
personally want is not relevant to the point I am trying to make.
> (setf cl-standard-library (cons "cl-ppcre" nil))
> (push "clsql" cl-standard-library)
>
> Poof - a standard library.
Yes. But not *the* standard library.
rg
Ron Garret <·········@flownet.com> writes:
> Almost. It needs a web page full of pointers to documentation of the
> STANDARD library. And, of course, before that can be done there has to
> first exist a standard library to document.
I think this is a good idea, and I have thought about it before. The
"standard" (sigh, whatever that means) library's components are, for the
most part, already out there. What would be necessary to make it feel
like an integrated library is to agree on things like documentation
conventions and formats (e.g. Texinfo?) that can be compiled into a
single manual (easy to do with Texinfo).
This is probably within the scope of the Alexandria project over at
c-l.net. I don't have time right now to do it on my own, but if you
start such an effort you can count with my help. Just the documentation
integration might be a good start, then having automated integration
tests and "standard library releases" would be the next step I suppose.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Luís Oliveira wrote:
> Ron Garret <·········@flownet.com> writes:
>> Almost. It needs a web page full of pointers to documentation of the
>> STANDARD library. And, of course, before that can be done there has to
>> first exist a standard library to document.
>
> I think this is a good idea, and I have thought about it before. The
> "standard" (sigh, whatever that means) library's components are, for the
> most part, already out there. What would be necessary to make it feel
> like an integrated library is to agree on things like documentation
> conventions and formats (e.g. Texinfo?) that can be compiled into a
> single manual (easy to do with Texinfo).
>
> This is probably within the scope of the Alexandria project over at
> c-l.net. I don't have time right now to do it on my own, but if you
> start such an effort you can count with my help. Just the documentation
> integration might be a good start, then having automated integration
> tests and "standard library releases" would be the next step I suppose.
This sounds like a "big bang" approach. Wouldn't it make more sense to
collect the various specs and, for example, submit them as documents to
CDR - http://cdr.eurolisp.org ? This would at least give people a handle
to unambiguously refer to such libraries (the most important aspect of
standardization, IMHO).
A next step could then be separate documents that simply enumerate all
the CDRs that are supposed to be (useful) bundles of such libraries...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> This sounds like a "big bang" approach. Wouldn't it make more sense to
> collect the various specs and, for example, submit them as documents
> to CDR - http://cdr.eurolisp.org ? This would at least give people a
> handle to unambiguously refer to such libraries (the most important
> aspect of standardization, IMHO).
I don't think the CDR and this *hypothetical* project would be competing
in any way. I like the CDR idea but I don't see how it helps generating
consistent documentation and ensuring proper testing for a wide set of
libraries (I'm particularly concerned with dependencies among them) on a
large number of implementations.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Brian Adkins <·················@gmail.com> writes:
>
> I asked, in effect, what aspects of the Python standard library you
>felt were important and/or indicative of a lack in CL, and you reply
>that it's not the modules but the *page*. So your grand point in
>response to what CL needs to evolve is a better web page full of
>pointers to library documentation. Sheesh...
I think his points are that these are the _standard_ modules, that they
are documented as such, and that they are available everywhere, on all
platforms and in all implementations.
I'm a bit confused as to why so many Common Lisp folks hate the idea of
a nice comprehensive standard library, or at least don't see any real
need for it. After all, CL had what at one time was considered a pretty
large standard library--after all, it built OOP, hash tables _and_
complex numbers into the language!
--
Robert Uhl <http://public.xdi.org/=ruhl>
It is the way of the young both to be certain of their own course and to
feel much abused when their elders do not share their certainty.
--David Weber
Robert Uhl <·········@NOSPAMgmail.com> writes:
> I'm a bit confused as to why so many Common Lisp folks hate the idea of
> a nice comprehensive standard library, or at least don't see any real
> need for it.
I think a nice standard library of useful stuff would be great. I
haven't noticed many people disparaging the idea of it. I think it
would be a tremendous amount of work, and few people willing & able to
undertake it.
I frequently see a sort of fake roadblock pattern:
A: I want to use Lisp, what library do I use for <portable sockets,
small delivered images on free Lisps, threads, Unicode, bivalent
I/O, cross-platform GUIs, etc>?
B: There isn't really anything that fully fits that description.
A: Damn, what a shame, guess I can't use Lisp!
B: Well, that's not usually a major roadblock to getting useful
work done, you have a number of ways to proceed...
C: Wow, why does the Lisp community hate <whatever>?
There are, of course, more and less sane variations on all these
interactions. I think most CL users would welcome any sort of new,
useful, high quality software for CL, but will continue to find ways
to get useful work done until it appears out of the blue.
And kudos to people like Marc Battyani, Edi Weitz, Sven Van C10e,
Kevin Rosenberg, etc, who write great, useful CL software and share it
with the world, instead of wasting time posting to Usenet like me. :)
Zach
On Mon, 02 Apr 2007 13:10:24 -0600, Robert Uhl wrote:
> Brian Adkins <·················@gmail.com> writes:
>>
>> I asked, in effect, what aspects of the Python standard library you
>>felt were important and/or indicative of a lack in CL, and you reply
>>that it's not the modules but the *page*. So your grand point in
>>response to what CL needs to evolve is a better web page full of
>>pointers to library documentation. Sheesh...
>
> I think his points are that these are the _standard_ modules, that they
> are documented as such, and that they are available everywhere, on all
> platforms and in all implementations.
Clearly. And yet when I continued to ask for something specific that might
be helpful such as which modules in particular he would like to see in the
standard library, he continually spewed gibberish such as "it's not about
the modules it's about the *page*", etc.
So let me ask you:
1) Which currently existing libraries would you like to see in a
"standard" library?
2) If there is functionality that is not provided by an existing CL
library that you feel is important, what is it?
Or possibly you have a better idea of how to proceed. What do you think
the process of creating a standard library should look like? Let's assume
for the sake of discussion that a formal process such as ANSI is not
feasible.
> I'm a bit confused as to why so many Common Lisp folks hate the idea of
> a nice comprehensive standard library, or at least don't see any real
> need for it. After all, CL had what at one time was considered a pretty
> large standard library--after all, it built OOP, hash tables _and_
> complex numbers into the language!
Yes, you appear to be confused. Are you perhaps mistaking people who
complain about the lack of a standard library for those who like it, and
mistaking people who complain about such people for those who don't like a
standard library?
If what you say is true, surely you can name many CL people who "hate the
idea of a nice comprehensive standard library". I'm curious who they are
because I can't think of any. What disadvantage do you think these
imagined people see in having a "nice standard library" ?
Brian Adkins <·················@gmail.com> writes:
> So let me ask you:
> 1) Which currently existing libraries would you like to see in a
> "standard" library?
If it can be put in a library, then it probably doesn't belong to the
CL standard.
What needs to be integrated in a new version of the CL standard are
primitive extensions that cannot be easily implemented in a library.
(That and some cleanup of stuff like pathnames).
Candidates could be weak pointers, standard FFI (there's CFFI, but
it's built over implementation dependant FFI API, there's no reason
why not have a single standard one), readtable data structure access
(a hook in the token parsing routine, and access to the syntax table),
multi-processing (when the invasion of the multi-core processors is
close!), etc.
> 2) If there is functionality that is not provided by an existing CL
> library that you feel is important, what is it?
No, the question should be if there is (primitive) functionality that
is not provided by an existing CL implementation that you feel is
important, what is it?
With good _standard_ primitives, portable libraries can easily be
developed and become de-facto standards.
--
__Pascal Bourguignon__
http://www.informatimago.com
http://pjb.ogamita.org
On Apr 4, 8:41 am, Pascal Bourguignon <····@informatimago.com> wrote:
>
> If it can be put in a library, then it probably doesn't belong to the
> CL standard.
I disagree. One major purpose of a standard (in the informal sense),
in my view, is to make it possible for portable programs to be written
at a reasonably high level. Just because something could be
implemented in a library does not mean it should not be standardised,
because programs written at this high level will depend on the library
just as much as they will on the underlying functionality.
An example (not a Lisp example) might be HTTP. Clearly, given a
standard interface to TCP, HTTP is just a library, as are virtually
all application protocols. This does not mean that standards for
them, and standard interfaces to them, are not desirable.
Obviously there are different views of standards & room for layering.
--tim
Pascal Bourguignon <···@informatimago.com> writes:
>
> If it can be put in a library, then it probably doesn't belong to the
> CL standard.
Well, you just excluded CLOS, hash tables and integers from the
standard...
--
Robert Uhl <http://public.xdi.org/=ruhl>
> Then again, this is still an Internet where the appropriately named
> Domino server
It's not appropriately named; it should be called Lotus House of Cards.
--Steve Sobol, in response to Alan Brown
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>>
>> If it can be put in a library, then it probably doesn't belong to the
>> CL standard.
>
> Well, you just excluded CLOS, hash tables and integers from the
> standard...
On the other hand, weak hash-tables no. :-)
But you'r right, the question is the "can be put", considering not
only theorical possibility, but practical consequences like
performance.
--
__Pascal Bourguignon__
http://www.informatimago.com
http://pjb.ogamita.org
Brian Adkins <·················@gmail.com> writes:
>
>> I think his points are that these are the _standard_ modules, that
>> they are documented as such, and that they are available everywhere,
>> on all platforms and in all implementations.
>
> Clearly. And yet when I continued to ask for something specific that
> might be helpful such as which modules in particular he would like to
> see in the standard library, he continually spewed gibberish such as
> "it's not about the modules it's about the *page*", etc.
I think that what he meant by all that about 'the *page*' and so forth
was that there was a definitive standard. I don't think English is his
first language.
> So let me ask you:
> 1) Which currently existing libraries would you like to see in a
> "standard" library?
ASDF, ASDF-INSTALL, CLSQL, CL-PPCRE. Probably also Hunchentoot, maybe
Drakma. CL-EMB, perhaps also CL-WHO. CL-NCURSES.
> 2) If there is functionality that is not provided by an existing CL
> library that you feel is important, what is it?
Stuff to make Unixy shell scripting simpler--much like the pipes macro
recently posted. Some wrappers to make calling a shell command as
simple as (shell "ls -a /foo/bar") and (shell "ls" "-a" "/foo/bar")
(doing the Right Thing in both cases, which is bit tricky).
_Maybe_ a standard non-buggy GTK+ interface.
A bunch of stuff modelled after Python modules. Parts of some of these
are in the standard; parts are provided by various implementations;
parts are provided by existing libraries.
o datetime
o mutex
o weakref
o email
o mimetools
o multifile
o rfc822
o base64
o uu
o htmllib
o netrc
o md5
o sha
o pickle
o os
o getpass
o thread or threading
o posix
o readline
o socket
o urllib or urllib2
o ftplib
o smtplib
o uuid
o SocketServer
Much of what doesn't already exist is easily written; however, it's not
particularly interesting. The advantages of a standard version are: not
having to roll one's own; not having to debug one's one; not having to
understand another's; not finding bugs in another's.
> Or possibly you have a better idea of how to proceed. What do you
> think the process of creating a standard library should look like?
> Let's assume for the sake of discussion that a formal process such as
> ANSI is not feasible.
I don't think it's possible, to tell the truth. The vendors (whether
proprietary or free) aren't really interested in commonality beyond the
spec; the commercial vendors understandably want a competitive
difference between their products and their competitors'; the free
vendors understandably are interested in working on what they find
interesting.
In other words, a comprehensive standard library is both desirable and
highly improbable.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I have a dream: 2,199,023,255,552 bytes free. -- bash.org/?328
On Thu, 05 Apr 2007 11:31:21 -0600, Robert Uhl wrote:
> Brian Adkins <·················@gmail.com> writes:
>>
>> So let me ask you:
>> 1) Which currently existing libraries would you like to see in a
>> "standard" library?
>
> ASDF, ASDF-INSTALL, CLSQL, CL-PPCRE. Probably also Hunchentoot, maybe
> Drakma. CL-EMB, perhaps also CL-WHO. CL-NCURSES.
>
>> 2) If there is functionality that is not provided by an existing CL
>> library that you feel is important, what is it?
>
> Stuff to make Unixy shell scripting simpler--much like the pipes macro
> recently posted. Some wrappers to make calling a shell command as
> simple as (shell "ls -a /foo/bar") and (shell "ls" "-a" "/foo/bar")
> (doing the Right Thing in both cases, which is bit tricky).
>
> _Maybe_ a standard non-buggy GTK+ interface.
>
> A bunch of stuff modelled after Python modules. Parts of some of these
> are in the standard; parts are provided by various implementations;
> parts are provided by existing libraries.
>
> o datetime
> o mutex
> o weakref
> o email
> o mimetools
> o multifile
> o rfc822
> o base64
> o uu
> o htmllib
> o netrc
> o md5
> o sha
> o pickle
> o os
> o getpass
> o thread or threading
> o posix
> o readline
> o socket
> o urllib or urllib2
> o ftplib
> o smtplib
> o uuid
> o SocketServer
>
> Much of what doesn't already exist is easily written; however, it's not
> particularly interesting. The advantages of a standard version are: not
> having to roll one's own; not having to debug one's one; not having to
> understand another's; not finding bugs in another's.
>
>> Or possibly you have a better idea of how to proceed. What do you
>> think the process of creating a standard library should look like?
>> Let's assume for the sake of discussion that a formal process such as
>> ANSI is not feasible.
>
> I don't think it's possible, to tell the truth. The vendors (whether
> proprietary or free) aren't really interested in commonality beyond the
> spec; the commercial vendors understandably want a competitive
> difference between their products and their competitors'; the free
> vendors understandably are interested in working on what they find
> interesting.
It makes sense for the commercial vendors to create a competitive
advantage. Unfortunately, as the benefit of functionality rises, so does
the fear of possible lock-in abuse.
I don't think the vendors even need to be involved in the creation of a
"common library". I'll use that term instead of "standard library" to
avoid preconceived ideas of formal processes, etc. If the common library
conforms to the ANSI Common Lisp spec, then it should work with any
implementation that conforms to CL.
As an example, how difficult would it be to port a significant chunk of
Python's or Ruby's standard library it to Lisp? Surely it would be easier
than creating a brand new language plus library from scratch, right? I
suppose not having a BDFL could be a hindrance (possibly resulting in
design-by-committee problems), but whatever processes have created the
Python or Ruby standard libraries should be able to work in the creation
of a common library for Lisp.
My sense is that a large number of ingredients already exist (i.e.
libraries you mention above). Maybe a reasonable process would be similar
to the following:
1) Identify existing libraries suitable for inclusion as-is
2) Identify existing libraries suitable for inclusion with-some-changes
2a) Make changes
3) Identify desired functionality not provided by an existing library
3a) Write/port libraries
4) Create an easily installable package plus documentation
Just as an example, Ruby comes with 48 built-in classes/modules (266 pages
of doc in "Programming Ruby") and 98 standard libraries/classes/modules
(107 pages of doc in "Programming Ruby").
The goal would be an easily installable highly functional common library
that would work on multiple implementations of Lisp. I would even avoid
using the term "standard library" because creating something that would
live up to that would IMO be improbable as you suggest. But something to
merely match Python or Ruby (to use reasonable examples) shouldn't be
*that* daunting.
It might even be beneficial to simply define the interfaces of desired
functionality and allow multiple implementations with various run-time
tradeoffs - a library spec if you will.
> In other words, a comprehensive standard library is both desirable and
> highly improbable.
Brian Adkins <·················@gmail.com> writes:
>
> I don't think the vendors even need to be involved in the creation of a
> "common library". I'll use that term instead of "standard library" to
> avoid preconceived ideas of formal processes, etc. If the common library
> conforms to the ANSI Common Lisp spec, then it should work with any
> implementation that conforms to CL.
Most of the stuff I'm thinking of could be developed in
implementation-independent CL, yes. I think that having vendors
involved would be a good thing anyway though, since ideally a user could
just rely on the common/standard library just being present.
> As an example, how difficult would it be to port a significant chunk
> of Python's or Ruby's standard library it to Lisp?
Can;t be too difficult. I started playing with a UUID library, but was
too lazy to figure the offset since CL can't handle dates before 1
January 1900 (or is it 1901?).
> I suppose not having a BDFL could be a hindrance (possibly resulting
> in design-by-committee problems), but whatever processes have created
> the Python or Ruby standard libraries should be able to work in the
> creation of a common library for Lisp.
I think that one aid is having a BDFL--someone submits a library, he
likes it, it becomes part of the standard install. The Lisp situation
is different: CL-PPCRE is universally recognised as excellent, and yet
AFAIK it's not included in any implementation's standard distribution.
> The goal would be an easily installable highly functional common
> library that would work on multiple implementations of Lisp.
Again one gets into the problem of multiple implementations. Library A
might work on CLISP, SBCL, LispWorks and ABCL, while Library B might
work on SBCL, CMUCL and Allegro; Library C might work on GCL, LispWorks
and Allegro. It may be that the maintainer of one library is willing to
take patches for some versions but not others.
And then there are licensing issues. It all gets quite complex.
> It might even be beneficial to simply define the interfaces of desired
> functionality and allow multiple implementations with various run-time
> tradeoffs - a library spec if you will.
In an Ideal World According to Bob, the ANSI standard would specify a
nice full-featured standard library, and implementors would implement it
in their own ways. Indeed, that's what it did (see packages, pathnames,
conditions and hash tables); for the time this was pretty incredible.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Many that live deserve death. And some that die deserve life. Can
you give that to them? Then be not too eager to deal out death in the
name of justice, fearing for your own safety. Even the wise cannot
see all ends. --J.R.R. Tolkien
On Sun, 08 Apr 2007 01:36:53 -0600, Robert Uhl wrote:
> Brian Adkins <·················@gmail.com> writes:
>>
>> I don't think the vendors even need to be involved in the creation of a
>> "common library". I'll use that term instead of "standard library" to
>> avoid preconceived ideas of formal processes, etc. If the common library
>> conforms to the ANSI Common Lisp spec, then it should work with any
>> implementation that conforms to CL.
>
> Most of the stuff I'm thinking of could be developed in
> implementation-independent CL, yes. I think that having vendors
> involved would be a good thing anyway though, since ideally a user could
> just rely on the common/standard library just being present.
I agree that if the common library came with the Lisp implementation it
would be even more convenient, but my idea would just be one step worse.
1) Install your favorite Lisp implementation
2) Install the common library
I expect getting all the vendors to agree to ship it will just not happen,
so step 2 will be necessary IMO.
>
>> As an example, how difficult would it be to port a significant chunk of
>> Python's or Ruby's standard library it to Lisp?
>
> Can;t be too difficult. I started playing with a UUID library, but was
> too lazy to figure the offset since CL can't handle dates before 1
> January 1900 (or is it 1901?).
>
>> I suppose not having a BDFL could be a hindrance (possibly resulting in
>> design-by-committee problems), but whatever processes have created the
>> Python or Ruby standard libraries should be able to work in the
>> creation of a common library for Lisp.
>
> I think that one aid is having a BDFL--someone submits a library, he
> likes it, it becomes part of the standard install. The Lisp situation
> is different: CL-PPCRE is universally recognised as excellent, and yet
> AFAIK it's not included in any implementation's standard distribution.
I expect it will be one of the first inclusions in the common library.
>> The goal would be an easily installable highly functional common
>> library that would work on multiple implementations of Lisp.
>
> Again one gets into the problem of multiple implementations. Library A
> might work on CLISP, SBCL, LispWorks and ABCL, while Library B might
> work on SBCL, CMUCL and Allegro; Library C might work on GCL, LispWorks
> and Allegro. It may be that the maintainer of one library is willing to
> take patches for some versions but not others.
If a library doesn't adhere to ANSI CL, then it won't be in the common
library. If it does adhere to ANSI CL, it should work on any compliant
implementation. Problem solved.
>
> And then there are licensing issues. It all gets quite complex.
Good point, but I expect if the common library gets traction and uses a
"reasonable" open source license, then library owners/maintainers may be
willing to release their library under that license. I wonder how much
variation exists among Lisp libraries currently. Are they all over the
map, or are only a few licenses being used by the "good" libraries.
>
>> It might even be beneficial to simply define the interfaces of desired
>> functionality and allow multiple implementations with various run-time
>> tradeoffs - a library spec if you will.
>
> In an Ideal World According to Bob, the ANSI standard would specify a
> nice full-featured standard library, and implementors would implement it
> in their own ways. Indeed, that's what it did (see packages, pathnames,
> conditions and hash tables); for the time this was pretty incredible.
Not going to happen - get over it :)
On Apr 9, 5:25 am, Brian Adkins <·················@gmail.com> wrote:
> On Sun, 08 Apr 2007 01:36:53 -0600, Robert Uhl wrote:
> > Brian Adkins <·················@gmail.com> writes:
>
> >> I don't think the vendors even need to be involved in the creation of a
> >> "common library". I'll use that term instead of "standard library" to
> >> avoid preconceived ideas of formal processes, etc. If the common library
> >> conforms to the ANSI Common Lisp spec, then it should work with any
> >> implementation that conforms to CL.
>
> > Most of the stuff I'm thinking of could be developed in
> > implementation-independent CL, yes. I think that having vendors
> > involved would be a good thing anyway though, since ideally a user could
> > just rely on the common/standard library just being present.
>
> I agree that if the common library came with the Lisp implementation it
> would be even more convenient, but my idea would just be one step worse.
> 1) Install your favorite Lisp implementation
> 2) Install the common library
>
> I expect getting all the vendors to agree to ship it will just not happen,
> so step 2 will be necessary IMO.
Okay. Who wants to host The c.l.l Common Library?
I nominate the following for inclusion:
ASDF
ASDF-INSTALL - these two, because they're de facto standard package
manager for CL
CL-PPCRE - because it's good
CLSQL - dunno, because every language needs a DB interface?
Cells - I hear it's good. Can't speak for myself, but I hear it's
good.
Sincerely,
AmkG
Robert Uhl wrote:
> Brian Adkins <·················@gmail.com> writes:
>> I asked, in effect, what aspects of the Python standard library you
>> felt were important and/or indicative of a lack in CL, and you reply
>> that it's not the modules but the *page*. So your grand point in
>> response to what CL needs to evolve is a better web page full of
>> pointers to library documentation. Sheesh...
>
> I think his points are that these are the _standard_ modules, that they
> are documented as such, and that they are available everywhere, on all
> platforms and in all implementations.
>
> I'm a bit confused as to why so many Common Lisp folks hate the idea of
> a nice comprehensive standard library, or at least don't see any real
> need for it. After all, CL had what at one time was considered a pretty
> large standard library--after all, it built OOP, hash tables _and_
> complex numbers into the language!
I don't think anybody "hates" the idea of a standard library. There is
just some disagreement about how to get there.
The OP asked for rebooting the ANSI CL standardization process (or for
something similar), maybe without being aware of it. IMHO, that would be
too costly and wouldn't pay off. It would probably take several years,
cost a lot of money, and until the final publication of such a new
standard, everybody would have to live with the current state of affairs
anyway.
There are cheaper and more light-weight ways to get similar effects with
a more immediate return on investment. There are actually quite a few
people working on the necessary ingredients and the situation is
continuously improving. This includes technical infrastructure
(asdf-install, etc.), library repositories (cliki.net, common-lisp.net,
cl-user.net) and document repositories (cdr.eurolisp.org).
It's just not a "big bang" approach, that's why some people seem to have
a hard time to notice the actual improvements.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Wed, 28 Mar 2007 02:31:06 +0200, Ron Garret <·········@flownet.com>
wrote:
>
>> So here is a concrete question: What are you missing?
>
> http://www.python.org/doc/current/modindex.html
>
How do these libraries relate to a language revision?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
In article <·················@pandora.upc.no>,
"John Thingstad" <··············@chello.no> wrote:
> On Wed, 28 Mar 2007 02:31:06 +0200, Ron Garret <·········@flownet.com>
> wrote:
>
> >
> >> So here is a concrete question: What are you missing?
> >
> > http://www.python.org/doc/current/modindex.html
> >
>
> How do these libraries relate to a language revision?
A language's standard library is considered nowadays to be part and
parcel of the language. Much (some would say most) of the utility of a
language nowadays derives from the functionality provided by its
standard library. Depending on how you look at it, CL either has no
standard library, or it has a standard library that hasn't changed in 20
years.
rg
On Tue, 27 Mar 2007 23:37:20 -0700, Ron Garret wrote:
> In article <·················@pandora.upc.no>,
> "John Thingstad" <··············@chello.no> wrote:
>
>> On Wed, 28 Mar 2007 02:31:06 +0200, Ron Garret <·········@flownet.com>
>> wrote:
>>
>> >
>> >> So here is a concrete question: What are you missing?
>> >
>> > http://www.python.org/doc/current/modindex.html
>> >
>>
>> How do these libraries relate to a language revision?
>
> A language's standard library is considered nowadays to be part and
> parcel of the language. Much (some would say most) of the utility of a
> language nowadays derives from the functionality provided by its
> standard library. Depending on how you look at it, CL either has no
> standard library, or it has a standard library that hasn't changed in 20
> years.
http://www.cliki.net/index
>
> rg
In article <······························@gmail.com>,
Brian Adkins <·················@gmail.com> wrote:
> On Tue, 27 Mar 2007 23:37:20 -0700, Ron Garret wrote:
>
> > In article <·················@pandora.upc.no>,
> > "John Thingstad" <··············@chello.no> wrote:
> >
> >> On Wed, 28 Mar 2007 02:31:06 +0200, Ron Garret <·········@flownet.com>
> >> wrote:
> >>
> >> >
> >> >> So here is a concrete question: What are you missing?
> >> >
> >> > http://www.python.org/doc/current/modindex.html
> >> >
> >>
> >> How do these libraries relate to a language revision?
> >
> > A language's standard library is considered nowadays to be part and
> > parcel of the language. Much (some would say most) of the utility of a
> > language nowadays derives from the functionality provided by its
> > standard library. Depending on how you look at it, CL either has no
> > standard library, or it has a standard library that hasn't changed in 20
> > years.
>
> http://www.cliki.net/index
Yes, the distinction between that and the URL that I cited would be
precisely my point.
rg
On Wed, 28 Mar 2007 09:37:02 -0700, Ron Garret wrote:
> In article <······························@gmail.com>,
> Brian Adkins <·················@gmail.com> wrote:
>
>> On Tue, 27 Mar 2007 23:37:20 -0700, Ron Garret wrote:
>>
>> > In article <·················@pandora.upc.no>,
>> > "John Thingstad" <··············@chello.no> wrote:
>> >
>> >> On Wed, 28 Mar 2007 02:31:06 +0200, Ron Garret <·········@flownet.com>
>> >> wrote:
>> >>
>> >> >
>> >> >> So here is a concrete question: What are you missing?
>> >> >
>> >> > http://www.python.org/doc/current/modindex.html
>> >> >
>> >>
>> >> How do these libraries relate to a language revision?
>> >
>> > A language's standard library is considered nowadays to be part and
>> > parcel of the language. Much (some would say most) of the utility of a
>> > language nowadays derives from the functionality provided by its
>> > standard library. Depending on how you look at it, CL either has no
>> > standard library, or it has a standard library that hasn't changed in 20
>> > years.
>>
>> http://www.cliki.net/index
>
> Yes, the distinction between that and the URL that I cited would be
> precisely my point.
Well, it is a wiki, right? Have you tried editing it to be closer to your
ideal?
>
> rg
In article <······························@gmail.com>,
Brian Adkins <·················@gmail.com> wrote:
> On Wed, 28 Mar 2007 09:37:02 -0700, Ron Garret wrote:
>
> > In article <······························@gmail.com>,
> > Brian Adkins <·················@gmail.com> wrote:
> >
> >> On Tue, 27 Mar 2007 23:37:20 -0700, Ron Garret wrote:
> >>
> >> > In article <·················@pandora.upc.no>,
> >> > "John Thingstad" <··············@chello.no> wrote:
> >> >
> >> >> On Wed, 28 Mar 2007 02:31:06 +0200, Ron Garret <·········@flownet.com>
> >> >> wrote:
> >> >>
> >> >> >
> >> >> >> So here is a concrete question: What are you missing?
> >> >> >
> >> >> > http://www.python.org/doc/current/modindex.html
> >> >> >
> >> >>
> >> >> How do these libraries relate to a language revision?
> >> >
> >> > A language's standard library is considered nowadays to be part and
> >> > parcel of the language. Much (some would say most) of the utility of a
> >> > language nowadays derives from the functionality provided by its
> >> > standard library. Depending on how you look at it, CL either has no
> >> > standard library, or it has a standard library that hasn't changed in 20
> >> > years.
> >>
> >> http://www.cliki.net/index
> >
> > Yes, the distinction between that and the URL that I cited would be
> > precisely my point.
>
> Well, it is a wiki, right? Have you tried editing it to be closer to your
> ideal?
The fact that it is a wiki is a bug, not a feature. The problem I am
trying to highlight is not that CL has no documentation for its standard
library, but rather that is has no standard library. Worse, it has no
process for creating one. Still worse, it has a user community that
doesn't seem to think this is a problem.
All IMHO of course.
rg
Ron Garret wrote:
> The problem I am
> trying to highlight is not that CL has no documentation for its standard
> library, but rather that is has no standard library. Worse, it has no
> process for creating one. Still worse, it has a user community that
> doesn't seem to think this is a problem.
The Lisp standard library is listed halfway down this page:
http://www.cliki.net/ASDF-Install
Which other language comes standard with a Porter Stemmer or ARM compiler?
- DH
In article <································@comcast.com>,
D Herring <········@at.tentpost.dot.com> wrote:
> Ron Garret wrote:
> > The problem I am
> > trying to highlight is not that CL has no documentation for its standard
> > library, but rather that is has no standard library. Worse, it has no
> > process for creating one. Still worse, it has a user community that
> > doesn't seem to think this is a problem.
>
> The Lisp standard library is listed halfway down this page:
> http://www.cliki.net/ASDF-Install
Google thinks the Lisp standard library is here (the top result for
"lisp standard library"):
http://www.damtp.cam.ac.uk/user/sje30/emacs/ell.html
or maybe here (the top result for "common lisp standard library"):
http://common-lisp.net/project/cl-utilities/
The cliki page doesn't show up in the top 10 for either query. This is
not to say that it's a bad page, just that it is far from clear that
this is the standard library.
> Which other language comes standard with a Porter Stemmer or ARM compiler?
By your precedent, just about every language in existence:
http://www.tartarus.org/~martin/PorterStemmer/
rg
On Wed, 28 Mar 2007 08:37:20 +0200, Ron Garret <·········@flownet.com>
wrote:
>
> A language's standard library is considered nowadays to be part and
> parcel of the language. Much (some would say most) of the utility of a
> language nowadays derives from the functionality provided by its
> standard library. Depending on how you look at it, CL either has no
> standard library, or it has a standard library that hasn't changed in 20
> years.
>
> rg
Oh yeah. So what you are basically saying is that no language can make it
if
it doesn't has a language library to match Java, Perl, Ruby or Python's.
1. Well my Lisp does. I use Windows and through RDNZL I have access to the
entire
.NET library which easily matches Java's. Today..
The need to redefine a library for each language amounts to huge
amount of redundancy, memory waste and time.
2. All the languages in 1. are provided by one vendor and they are all
free.
The criteria don't apply to CL. Who would pay for the effort?
Certainly not the commercial vendors. It is better custom libraries
that set them appart.
3. Portable libraries that are not standard are a viable option.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
In article <·················@pandora.upc.no>,
"John Thingstad" <··············@chello.no> wrote:
> On Wed, 28 Mar 2007 08:37:20 +0200, Ron Garret <·········@flownet.com>
> wrote:
>
> >
> > A language's standard library is considered nowadays to be part and
> > parcel of the language. Much (some would say most) of the utility of a
> > language nowadays derives from the functionality provided by its
> > standard library. Depending on how you look at it, CL either has no
> > standard library, or it has a standard library that hasn't changed in 20
> > years.
> >
> > rg
>
> Oh yeah. So what you are basically saying is that no language can make it
> if
> it doesn't has a language library to match Java, Perl, Ruby or Python's.
No, that is not what I said. If you want to argue with yourself be my
guest, but if you want to debate me you will have to address what I
actually said, not what you would like to imagine that I said.
rg
"John Thingstad" <··············@chello.no> writes:
> Oh yeah. So what you are basically saying is that no language can make
> it if it doesn't has a language library to match Java, Perl, Ruby or
> Python's.
>
> 1. Well my Lisp does. I use Windows and through RDNZL I have access to
> the entire .NET library which easily matches Java's. Today.. The need
> to redefine a library for each language amounts to huge amount of
> redundancy, memory waste and time.
Don't forget ABCL, which provides access to Java classes and libraries.
Runs everywhere Java runs, and can let you for example run Lisp code
inside Java application servers etc (I have done this).
--
vsync
http://quadium.net/~vsync/
Every answer asks a more beautiful question.
-- http://www.cyberciti.biz/faq/
Ron Garret wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Evolution doesn't guarantee improvement.
>
> Different is not necessarily better. But better is necessarily
> different.
Fortunately, Common Lisp is quite different. ;)
>> An evolution could actually mean that things get worse
>
> There is no reward without risk.
>
>> So here is a concrete question: What are you missing?
>
> http://www.python.org/doc/current/modindex.html
You're certainly aware of the fact that Common Lisp is not a programming
language, but a family of languages.
So here is an (incomplete) set of links to choose from:
+ http://www.franz.com/support/documentation/8.0/doc/contents.htm
+ http://clisp.cons.org/impnotes/extensions.html
+ http://common-lisp.net/project/cmucl/doc/cmu-user/
+ http://www.cormanlisp.com/features.html
+ http://www.lispworks.com/documentation/index.html and
http://www.lispworks.com/documentation/lw50/LWUG/html/lwuser-5.htm#pgfId-886036
+ http://openmcl.clozure.com/Doc/index.html
+ http://www.sbcl.org/manual/
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <···············@mid.individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Evolution doesn't guarantee improvement.
> >
> > Different is not necessarily better. But better is necessarily
> > different.
>
> Fortunately, Common Lisp is quite different. ;)
It is becoming less so all the time as other languages converge upon it.
(Actually, I hear all the cool kids are using Haskell nowadays. Now
*that's* different.)
>
> >> An evolution could actually mean that things get worse
> >
> > There is no reward without risk.
> >
> >> So here is a concrete question: What are you missing?
> >
> > http://www.python.org/doc/current/modindex.html
>
> You're certainly aware of the fact that Common Lisp is not a programming
> language, but a family of languages.
I knew that Lisp was a family. I was unaware that Common Lisp was
considered a family, and not a single language. I think that is most
regrettable. One of the other main factors that goes into language
choice nowadays (in industrial settings, which is the context that
nowadays matters to me) is the size of the user community. If you're
telling me that I can't choose "Common Lisp" as my language, but I have
to choose "Allegro Common Lisp" or "CLisp" or "SBCL" as my language,
then the size of the user community for each of those languages is even
smaller than the size of the user community for "Common Lisp". (This
kind of Balkanization is IMHO precisely the reason that no one ever does
any real work using Scheme, by which I mean that no one uses Scheme for
anything other than writing Scheme compilers).
If Common Lisp aspires to greater use (which is far from clear), I think
it would be wiser for the community to market itself (as it once did) as
a single language with multiple implementations.
rg
Ron Garret wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>> In article <···············@mid.individual.net>,
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>
>>>> Evolution doesn't guarantee improvement.
>>> Different is not necessarily better. But better is necessarily
>>> different.
>> Fortunately, Common Lisp is quite different. ;)
>
> It is becoming less so all the time as other languages converge upon it.
> (Actually, I hear all the cool kids are using Haskell nowadays. Now
> *that's* different.)
The hype is already over. ;) IIUC, people are going back to hybrid
languages, like OCaml or Clean.
>>>> An evolution could actually mean that things get worse
>>> There is no reward without risk.
>>>
>>>> So here is a concrete question: What are you missing?
>>> http://www.python.org/doc/current/modindex.html
>> You're certainly aware of the fact that Common Lisp is not a programming
>> language, but a family of languages.
>
> I knew that Lisp was a family. I was unaware that Common Lisp was
> considered a family, and not a single language.
From CLtL2 (Section 1.1):
"Common Lisp originated in an attempt to focus the work of several
implementation groups, each of which was constructing successor
implementations of MacLisp for different computers. These
implementations had begun to diverge because of the differences in the
implementation environments: microcoded personal computers (Zetalisp,
Spice Lisp), commercial timeshared computers (NIL-the ``New
Implementation of Lisp''), and supercomputers (S-1 Lisp). While the
differences among the several implementation environments of necessity
will continue to force certain incompatibilities among the
implementations, Common Lisp serves as a common dialect to which each
implementation makes any necessary extensions."
"It is intended that Common Lisp will change only slowly and with due
deliberation. The various dialects that are supersets of Common Lisp may
serve as laboratories within which to test language extensions, but such
extensions will be added to Common Lisp only after careful examination
and experimentation."
And, more to the point, from the HyperSpec (Section 1.1.2):
"Common Lisp was designed as a description of a family of languages."
> I think that is most
> regrettable. One of the other main factors that goes into language
> choice nowadays (in industrial settings, which is the context that
> nowadays matters to me) is the size of the user community. If you're
> telling me that I can't choose "Common Lisp" as my language, but I have
> to choose "Allegro Common Lisp" or "CLisp" or "SBCL" as my language,
> then the size of the user community for each of those languages is even
> smaller than the size of the user community for "Common Lisp". (This
> kind of Balkanization is IMHO precisely the reason that no one ever does
> any real work using Scheme, by which I mean that no one uses Scheme for
> anything other than writing Scheme compilers).
In my courses on theory of science, I have learned that empirical data
is useful to validate one's theories. Last time I checked, both Common
Lisp and Scheme were used in industrial settings.
> If Common Lisp aspires to greater use (which is far from clear), I think
> it would be wiser for the community to market itself (as it once did) as
> a single language with multiple implementations.
This is not about marketing. ANSI Common Lisp is just a specification,
nothing less, nothing more.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> And, more to the point, from the HyperSpec (Section 1.1.2):
>
> "Common Lisp was designed as a description of a family of languages."
I stand corrected.
> > I think that is most
> > regrettable. One of the other main factors that goes into language
> > choice nowadays (in industrial settings, which is the context that
> > nowadays matters to me) is the size of the user community. If you're
> > telling me that I can't choose "Common Lisp" as my language, but I have
> > to choose "Allegro Common Lisp" or "CLisp" or "SBCL" as my language,
> > then the size of the user community for each of those languages is even
> > smaller than the size of the user community for "Common Lisp". (This
> > kind of Balkanization is IMHO precisely the reason that no one ever does
> > any real work using Scheme, by which I mean that no one uses Scheme for
> > anything other than writing Scheme compilers).
>
> In my courses on theory of science, I have learned that empirical data
> is useful to validate one's theories. Last time I checked, both Common
> Lisp and Scheme were used in industrial settings.
Pardon me for engaging in hyperbole. By comparison to many other
languages, the extent to which Scheme is used in industrial settings is
negligible.
> > If Common Lisp aspires to greater use (which is far from clear), I think
> > it would be wiser for the community to market itself (as it once did) as
> > a single language with multiple implementations.
>
> This is not about marketing.
Of course it's about marketing. Whether or not CL is one language or a
family of languages is a purely artificial (and mostly arbitrary)
distinction. The only possible benefit to choosing one view over the
other is perception, which is to say, marketing.
rg
Ron Garret wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> And, more to the point, from the HyperSpec (Section 1.1.2):
>>
>> "Common Lisp was designed as a description of a family of languages."
>
> I stand corrected.
That's a good start, because everything else follows from there.
>>> If Common Lisp aspires to greater use (which is far from clear), I think
>>> it would be wiser for the community to market itself (as it once did) as
>>> a single language with multiple implementations.
>> This is not about marketing.
>
> Of course it's about marketing. Whether or not CL is one language or a
> family of languages is a purely artificial (and mostly arbitrary)
> distinction. The only possible benefit to choosing one view over the
> other is perception, which is to say, marketing.
It's about comparing apples to trees.
You simply cannot compare (ANSI) Common Lisp to, say, Python. You can
compare Common Lisp to the family of languages that consists of Python,
JPython, Stackless Python, IronPython, etc. pp. You can also compare
Common Lisp to the family of languages that consists of Ruby, JRuby,
Yarv, Ruby.NET, etc. pp.
So, what are *the* standard libraries for those family of languages? As
far as I can tell, there is no consensus of what is guaranteed to be
portable and what not in those language families. For example, it is
interesting to see how many "error" entries are in the tables listed at
http://antoniocangiano.com/articles/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal
Compare this, for example, to http://lispm.dyndns.org/lisp/benchmarks.html
I'd say that Common Lisp and Scheme are better off than those languages
because Common Lisp and Scheme have specifications that makes guarantees
about what is considered portable code and allows users to report
deviations as errors to the respective vendors. Languages like Python,
Ruby, and so on, are still at a stage that Lisp was before end of the
70's / beginning of the 80's in that regard.
What you seem to like about Python is that the one main implementation
of Python comes with a lot of libraries already bundled. You can get
exactly the same advantage with each instance of Common Lisp or Scheme.
You just have to commit yourself to a single implementation, and that's
no different to any other language out there.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 4957 September 1993, Pascal Costanza wrote:
> What you seem to like about Python is that the one main implementation
> of Python comes with a lot of libraries already bundled. You can get
> exactly the same advantage with each instance of Common Lisp or
> Scheme. You just have to commit yourself to a single implementation,
> and that's no different to any other language out there.
I don't believe that claim is true. Of the many newer libraries on the
block that come closest to being treated as de-facto standard
libraries, e.g. CLSQL, ASDF, CL-PPCRE, I am convinced that these are
still not shipping with your random CL implementation (SBCL ships
ASDF, but neither CL-PPCRE nor CLSQL; I'm not up to date wrt. the
commercial implementations).
But I think Rons point is mainly about the question what the de-facto
libraries are a CL programmer can expect to be installed with whatever
CL implementation he happens to like. And that's a question that
either gets answered by "some" magical standarization process, via
de-facto standardization (essentially magical in itself, i.e., somehow
all those vendors start shipping these libs), or not at all.
Actually, I would like to say I don't mind either way, heck, I know
how to install the libraries I need. But on the other hand, I've gone
through enough installation woes that I should know better.
Holger
--
--- http://hillview.bugwriter.net/ ---
"You see, when you upload, the computer has to push the bits upward,
and let me tell you, when you're talking millions of bits, it gets
heavy. When you download, the bits just fall by gravity, so it's much
faster (we provided you with some remarkable cushioning functions that
prevent damage to your data). Non-ADSL? They use helium. That's why
it's more expensive." -- seen on WTF
Pascal Costanza <··@p-cos.net> writes:
>
> What you seem to like about Python is that the one main implementation
> of Python comes with a lot of libraries already bundled. You can get
> exactly the same advantage with each instance of Common Lisp or
> Scheme. You just have to commit yourself to a single implementation,
> and that's no different to any other language out there.
You also need to commit to a proprietary implementation, don't you? At
least, I don't think that any of the free ones come with batteries
included...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Congratulations on deriving the density of the intergalactic medium to be
10^33 kg per cubic meter. That is 1,000,000,000,000,000,000,000,000,000,000
times more dense than if it was packed full of elephants. --Frossie
Robert Uhl wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> What you seem to like about Python is that the one main implementation
>> of Python comes with a lot of libraries already bundled. You can get
>> exactly the same advantage with each instance of Common Lisp or
>> Scheme. You just have to commit yourself to a single implementation,
>> and that's no different to any other language out there.
>
> You also need to commit to a proprietary implementation, don't you? At
> least, I don't think that any of the free ones come with batteries
> included...
There have already been a couple of attempts to create distributions
that include more than what the "plain" implementations provide. This
may or may not need improvement, but I cannot really judge this.
It's true, there is still a lot of work to do. Feel free to contribute... ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Robert Uhl wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>> What you seem to like about Python is that the one main implementation
>>> of Python comes with a lot of libraries already bundled. You can get
>>> exactly the same advantage with each instance of Common Lisp or
>>> Scheme. You just have to commit yourself to a single implementation,
>>> and that's no different to any other language out there.
>>
>> You also need to commit to a proprietary implementation, don't you? At
>> least, I don't think that any of the free ones come with batteries
>> included...
>
> There have already been a couple of attempts to create distributions
> that include more than what the "plain" implementations provide. This
> may or may not need improvement, but I cannot really judge this.
>
> It's true, there is still a lot of work to do. Feel free to
> contribute... ;)
Sorry, I didn't mean specifically you, so change this to: "Everyone,
feel free to contribute... ;)"
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/