Re: Modernizing Common Lisp

From: Tayssir John Gabbour (tayss_temp2_at_yahoo.com)
Date: 05/09/04 

Date: 9 May 2004 00:10:13 -0700

Hmm, I retract my ill-tempered post to which I am replying; I had felt
I wasted quite a few minutes of my life in an earlier thread where I
got the impression it was simply a debate.

I have no real opinion on this issue except that perhaps the current
formal standard has a timeless quality due to its generality; and I
hope no major, limiting alterations are made to it in this age of
commodity hardware. A more lightweight channel of "standardization"
would be preferable, because language can perhaps limit imagination.

-- Tayssir

tayss_temp2@yahoo.com (Tayssir John Gabbour) wrote in message news:<866764be.0405071002.573866aa@posting.google.com>...
> Dave Roberts <ldave-re-move@re-move.droberts.com> wrote in message news:<Rakmc.37505$0H1.3454523@attbi_s54>...
> > http://lists.tunes.org/archives/tunes/2001-February/003058.html
> >
> > The original message looks like it is over 5 years old. I found the
> > recommendations to be right on the money.
> >
> > I bring it up because of the two interesting recent threads titled:
> > 1. "Is anything easier to do in Java than in Lisp?"
> > 2. "The Hyperspec and portability between Common Lisp compilers (long)"
> >
> > Some of the areas for improvement suggested in this paper are things that I
> > think are important for modern programming with Lisp. Things like a
> > standard threads library and a standard network interface library are
> > critical for Lisp to be able to develop the set of general-purpose
> > libraries required for rich, modern applications. While many Lisps have
> > added features in these areas, without standardization the solutions are
> > fragmented and non-portable.
>
> You've made cogent points in the discussion, but I think most of it is
> wasted -- it was in response to the usual usenet bickering. Instead of
> focussing on the Why?, which I think is clear, I'd be interested in
> seeing a discussion of the proposals.
>
> - concurrent processor stuff: network, threads, db
> - ???
>
> What languages and lisp implementations do well on these things?
> Benefits/problems people encounter? What is hard to implement, and can
> there be different levels of conformance?
>
> What are the Lisps of these things, as opposed to the Javas and
> Pythons?
>
> I'm curious what peoples' thoughts are now about stack groups.
> http://bitsavers.org/pdf/mit/cadr/chineualJan84/chineualJun84_13_StackGroups.pdf
>
>
> I swear, if I see one more 200 post nontechnical thread saying why
> something can't be done and there's no point in educating oneself
> about it, I will go mental.

Relevant Pages

  • Modernizing Common Lisp
    ... "Is anything easier to do in Java than in Lisp?" ... standard threads library and a standard network interface library are ... libraries required for rich, modern applications. ... To help Lisp developers compete with Java and Python developers, ...
    (comp.lang.lisp)
  • Re: Modernizing Common Lisp
    ... > CL-PPCRE is the result of a bet. ... I imagine some new Lisp programmer who's perhaps used to ... Seeing nothing in the language standard about regexps, ... increasing the richness of libraries for Lisp. ...
    (comp.lang.lisp)
  • Re: Common Lisp from a Unix perspective - barriers to using CL
    ... facility for wrapper scripts, that I can put in a #! ... the standard facilities for building *portably-deployable* CL ... does not yet have a Lisp system'? ... useful other libraries, like HTML-TEMPLATE etc. ...
    (comp.lang.lisp)
  • Re: Modernizing Common Lisp
    ... To help Lisp developers compete with Java and Python developers, ... Instead, provide compatibility with the existing libraries, either Java ... > standard functionality that really works across all implementations. ...
    (comp.lang.lisp)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)