Common Lisp Extensions (Was: UK lispers mailing list) 
Author Message
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

> One relevant item that was discussed at the Cambridge meeting was the
> extent to which inter-vendor cooperation was possible and desireable:
> for instance, when an extension has been in the wild for a large
> amount of time, and is used at least by some users, maybe some
> harmonization across the vendor spectrum on even cosmetic things might
> be possible.  No firm decisions were made on this respect, but I
> thought I should say that it was brought up.

  I wonder why there is not a OpenGL-like standardization for Common
  Lisp? With OpenGL, there is several API levels. The standard set,
  the extension set and the vendor-specific set.

  Any vendor can extend the API using some rules (like a special
  package or function prefix). After a vote of all board members,
  these functions could switch to the official extension package of
  OpenGL. After a while (I don't know about the details), all
  extension functions will be included in the next release of the main
  OpenGL API.

  Generally, the most interesting vendor-specific API are quickly
  included in the extension set, so everybody can benefit of these
  extensions. You only use vendor-specific features for
  experimentation of future functionalities.

  Lisp vendors and some companies using the language should group
  together into a review board for these extensions. See what Sun did
  with their Java Community Process (www.jcp.org).

--
Frederic Brunel
Senior Software Engineer
In-Fusio - Mobile Game Connections



Fri, 19 Aug 2005 17:02:21 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:


> > One relevant item that was discussed at the Cambridge meeting was the
> > extent to which inter-vendor cooperation was possible and desireable:
> > for instance, when an extension has been in the wild for a large
> > amount of time, and is used at least by some users, maybe some
> > harmonization across the vendor spectrum on even cosmetic things might
> > be possible.  No firm decisions were made on this respect, but I
> > thought I should say that it was brought up.

>   I wonder why there is not a OpenGL-like standardization for Common
>   Lisp? With OpenGL, there is several API levels. The standard set,
>   the extension set and the vendor-specific set.

Isn't this, in theory anyway, one of the things the ALU is supposed to
do, i.e. "[support] the formation of inter-vendor standards."[1]. I
haven't read the whole ALU site but in what I did peruse I didn't find
anything about how exactly it supports the formation of such
standards. If I had a proposal, who would I send it to?

-Peter

[1] <http://www.lisp.org/table/about.htm#alu>

--

  The intellectual level needed   for  system design is  in  general
  grossly  underestimated. I am  convinced  more than ever that this
  type of work is very difficult and that every effort to do it with
  other than the best people is doomed to either failure or moderate
  success at enormous expense. --Edsger Dijkstra



Sat, 20 Aug 2005 02:43:35 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

> Isn't this, in theory anyway, one of the things the ALU is supposed to
> do, i.e. "[support] the formation of inter-vendor standards."[1]. I
> haven't read the whole ALU site but in what I did peruse I didn't find
> anything about how exactly it supports the formation of such
> standards. If I had a proposal, who would I send it to?

  I never seen anything coming from the ALU. I like what Sun did with
  their Java Community Process. I think there should be the same kind
  of Web site to help the Lisp users and companies to propose their
  extensions to the language standard. There is a lot of features to
  standardize between vendors like regular expressions, threads,
  sockets, database accesses or remote procedure calls as well as to
  deprecate some others.

--
Frederic Brunel

"You can't rush art."



Sat, 20 Aug 2005 06:27:18 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

>   There is a lot of features to
>   standardize between vendors like regular expressions, threads,
>   sockets, database accesses or remote procedure calls...

Don't vendors /compete/ on this basis? And don't they want to make
switching vendors /harder/, an argument for not standardizing?

OK, call me cynical...

:)

--

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
  the bath water is cold." -- Lorraine Lee Cudmore



Sat, 20 Aug 2005 08:24:56 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

> Don't vendors /compete/ on this basis? And don't they want to make
> switching vendors /harder/, an argument for not standardizing?

> OK, call me cynical...

> :)

Cynicism is against you.  My guess is that it's in the best interest of
the few Lisp vendors left to do whatever they can to make the language
thrive.

One wild card is the existence of the ANSI standard and the committee
that maintains it.  Theoretically they should be on the forefront of any
effort to keep the language growing.  But they have been inactive due to
lack of commercial participation.  For a university person to join, he
or she would have to convince the university or a funding agency to put
up some amount of money per year as dues to ANSI.  It's not a lot of
money; I forget the amount but it's on the order of a thousand bucks or
so.  So no universities and few private individuals are going to rush to
pitch in.  There are lots of companies willing to pay whatever W3C
charges, but not many interested in Lisp.

The time might be right to let the ANSI thing slide for a while and give
the community the responsibility for Lisp's evolution.  I don't think
there would be a shortage of volunteers.

     -- Drew McDermott



Sat, 20 Aug 2005 09:40:59 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:


>> Don't vendors /compete/ on this basis? And don't they want to make
>> switching vendors /harder/, an argument for not standardizing?
>> OK, call me cynical...
>> :)

> Cynicism is against you.  My guess is that it's in the best interest
> of the few Lisp vendors left to do whatever they can to make the
> language thrive.

Right.  Lisp vendors have an interest in helping to overcome what
I call "Norvig's checklist issue":

   "But the situation for Lisp in terms of popularity still
    reveals a weakness: the language standard has stagnated,
    without addressing some key issues like threading, sockets,
    and others. Furthermore, there is no well-known standard
    repository of libraries for new protocols like HTTP, HTML,
    XML, SOAP, etc. Individual implementations add libraries for
    these, and individual programmers create open-source
    implementations, but you don't get them right out of the box
    like you do with Java or Python, nor can you find them at a
    single location, like Perl's CPAN. This means that it takes
    more work to hunt these libraries down, and some programmers
    dismiss Lisp for a project because they don't immediately
    find the libraries they need."

from http://www.norvig.com/Lisp-retro.html

Quote:
> The time might be right to let the ANSI thing slide for a while and
> give the community the responsibility for Lisp's evolution.  I don't
> think there would be a shortage of volunteers.

This is already happening, so please ask Dan Barlow et al. about
the number of volunteers!

Dan Barlow's cirCLe proposal at http://www.cliki.net/circle is a
good roadmap for extending ANSI Lisp along lines which will
satisfy Norvig's checklist and more.  The next version of SBCL
will have native threads and a contrib/ directory with libraries
for at least sockets, rotate-byte, and building (asdf).

The vn-cclan archive network, http://www.cliki.net/cclan ,
piggybacks on the very successful Debian packaging system. Kevin
Rosenberg has debianized many libraries,
http://b9.com/debian.html .  From my experience with several of
these libraries, Debian itself goes halfway to serving the role
which CPAN plays for perl.

Chris



Sat, 20 Aug 2005 12:20:27 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:


> >   There is a lot of features to
> >   standardize between vendors like regular expressions, threads,
> >   sockets, database accesses or remote procedure calls...

> Don't vendors /compete/ on this basis? And don't they want to make
> switching vendors /harder/, an argument for not standardizing?

I dunno. I imagine this is a deeply multi-dimensional problem. On the
one hand, of course, the vendors can compete on features. But they can
also compete on support, etc. And they also would probably all rather
be getting a piece of a bigger total pie, i.e. if the Lisp market
grows, that's probably nothing but good for the vendors.

And having mulitple viable commercial vendors probably helps them
all--if we got down to one commercial vendor that one might be in
worse shape than if they still had a viable competitor because the
rest of the world would say, jeesh Lisp really is dead, all the
vendors are going out of business. (This insight came from someone at
the last Bay Area Lispniks meeting--I'll let him claim authorship if
he wants; I don't want to speak out of school.) Under this theory, the
existence of commercial vendors also gives the open source/free Lisps
support. And I suppose it works in reverse, the existence of open
source/free Lisps probably increases Lisp's general viability for a
lot of people and thus helps the commercial vendors.

Also, given that there are several viable open source/free Lisps, it's
possible that the commercial vendors could get some new features "for
free" merely by agreeing to adopt a (community) standardized way of
doing thing X if that thing X gets implemented in a portable way in an
open source project. (Or maybe "almost free" if the vendors have to do
some amount of work to tweak their implementation to support thing X.)

But I'm not personally trying to meet payroll at a commercial Lisp
vendor so I'm sure there's lots more subtleties to consider. (Just out
of curiosity, are any of the commercial Lisp vendors public companies?
Or are they all privately held?)

-Peter

--

  The intellectual level needed   for  system design is  in  general
  grossly  underestimated. I am  convinced  more than ever that this
  type of work is very difficult and that every effort to do it with
  other than the best people is doomed to either failure or moderate
  success at enormous expense. --Edsger Dijkstra



Sat, 20 Aug 2005 12:23:33 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:


>> Don't vendors /compete/ on this basis? And don't they want to make
>> switching vendors /harder/, an argument for not standardizing?
>> OK, call me cynical...
>> :)

> Cynicism is against you.  My guess is that it's in the best interest
> of the few Lisp vendors left to do whatever they can to make the
> language thrive.

Right.  Lisp vendors have an interest in helping to overcome what
I call "Norvig's checklist issue":

   "But the situation for Lisp in terms of popularity still
    reveals a weakness: the language standard has stagnated,
    without addressing some key issues like threading, sockets,
    and others. Furthermore, there is no well-known standard
    repository of libraries for new protocols like HTTP, HTML,
    XML, SOAP, etc. Individual implementations add libraries for
    these, and individual programmers create open-source
    implementations, but you don't get them right out of the box
    like you do with Java or Python, nor can you find them at a
    single location, like Perl's CPAN. This means that it takes
    more work to hunt these libraries down, and some programmers
    dismiss Lisp for a project because they don't immediately
    find the libraries they need."

from http://www.norvig.com/Lisp-retro.html

Quote:
> The time might be right to let the ANSI thing slide for a while and
> give the community the responsibility for Lisp's evolution.  I don't
> think there would be a shortage of volunteers.

This is already happening, so please ask Dan Barlow et al. about
the number of volunteers!

Dan Barlow's cirCLe proposal at http://www.cliki.net/circle is a
good roadmap for extending ANSI Lisp along lines which will
satisfy Norvig's checklist and more.  The next version of SBCL
will have native threads and a contrib/ directory with libraries
for at least sockets, rotate-byte, and building (asdf).

The vn-cclan archive network, http://www.cliki.net/cclan ,
piggybacks on the very successful Debian packaging system. Kevin
Rosenberg has debianized many libraries,
http://b9.com/debian.html .  From my experience with several of
these libraries, Debian itself goes halfway to serving the role
which CPAN plays for perl.

Chris



Sat, 20 Aug 2005 14:34:12 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

> Dan Barlow's cirCLe proposal at http://www.cliki.net/circle is a
> good roadmap for extending ANSI Lisp along lines which will
> satisfy Norvig's checklist and more.  The next version of SBCL
> will have native threads and a contrib/ directory with libraries
> for at least sockets, rotate-byte, and building (asdf).

Actually, the current version has contrib/ -- it was released a week or so
ago. :-)  Get it from
<http://sourceforge.net/project/showfiles.php?group_id=1373>, and see
if the system for managing libraries helps.  I believe that the next
Debian upload will also incorporate this work.

Native threads are probably going to be trickier to integrate, but
current progress is encouraging: see
<http://ww.telent.net/clim-address-book.png> for a native-thread SBCL
running CLX and McCLIM's address-book demo.

Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)



Sat, 20 Aug 2005 17:06:15 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

>   I never seen anything coming from the ALU. I like what Sun did with
>   their Java Community Process. I think there should be the same kind
>   of Web site to help the Lisp users and companies to propose their
>   extensions to the language standard. There is a lot of features to
>   standardize between vendors like regular expressions, threads,
>   sockets, database accesses or remote procedure calls as well as to
>   deprecate some others.

The problem is money.  Sun have poured a lot of money into the Java
community process, because they (rightly) see that any win for Java is
a win for them (better SGI or Linux win using Java than MS win using
C++).  If you want the ALU to do the same thing, then it needs money
(possibly from vendors, but our vendors do not have billions of
dollars in the bank like Sun).

--tim



Sat, 20 Aug 2005 18:11:02 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:


>>   their Java Community Process. I think there should be the same kind
>>   of Web site to help the Lisp users and companies to propose their

> The problem is money.  Sun have poured a lot of money into the Java
> community process, because they (rightly) see that any win for Java is
> a win for them (better SGI or Linux win using Java than MS win using
> C++).  If you want the ALU to do the same thing, then it needs money
> (possibly from vendors, but our vendors do not have billions of
> dollars in the bank like Sun).

In some communities there are movements going on below the "official
standardization process" level.  For C++ boost http://www.boost.org/ comes
to mind: A group of very skilled developers contributing and discussing
libraries which they hope will be standardized some day.  These people work
for free and they do an excellent job.  For Scheme there are the SRIs
http://srfi.schemers.org/ going in a similar direction.  For python there
are the PEPs http://www.python.org/peps/.  These efforts are tremendously
useful and really bring things forward without costing huge amounts of
money.  

Of course, there's a cost in terms of time to pay for the people who
contribute.  Nobody wants to pay that one unless seeing a chance that
contributions are actually recognized and have some sort of impact.  

Matthias



Sat, 20 Aug 2005 22:00:05 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

> Of course, there's a cost in terms of time to pay for the people who
> contribute.  Nobody wants to pay that one unless seeing a chance that
> contributions are actually recognized and have some sort of impact.  

Right, there is indeed such a cost.  The amount a community can afford
to spend on such efforts absent external funding depends on how large
it is - people can, perhaps, spend 5% of their time or something doing
free stuff.  So for the CL community, which is smaller than, say the
C++ community, correspondingly less is done.  But not nothing -
There are quasi-standard SQL bindings, foreign function call bindings
and so on, aren't there?

--tim



Sat, 20 Aug 2005 23:06:48 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

> But not nothing. There are quasi-standard SQL bindings, foreign
> function call bindings and so on, aren't there?

I'd say "no".  All the vendors have their own FFI.  IMHO, UFFI is an
adequate "lowest common denominator" solution but I wouldn't consider
it a standardized foreign function call interface.  

Also, "quasi-standard" is a long, long way from standard.  The
interfaces we already have in ANSI Common Lisp are powerful, elegant,
and generally well designed.  They've been discussed and polished for
a long time.  It would be a shame to start accepting any interface
(free or otherwise) with open arms and turn Common Lisp into PHP with
paranthesis...

Gabe Garza



Sat, 20 Aug 2005 23:58:19 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:


> >   There is a lot of features to
> >   standardize between vendors like regular expressions, threads,
> >   sockets, database accesses or remote procedure calls...

> Don't vendors /compete/ on this basis? And don't they want to make
> switching vendors /harder/, an argument for not standardizing?

What vendors?

(Ok, just joking.)  What a vendor wants is to attract and maintain a
customer base.  To prevent existing customers from leaving (the number
one priority!), they want to make sure that there is no advantage to
switching to another vendor.  So there is a strong incentive to
ensure that their product has *at least* as much functionality as the
competing product.  To entice competitor's customers to switch, they
have a strong incentive to *subsume* the competitor's API (so that
migration is trivial).

I think you'd find it easy to get competitors to agree on standards
that they already implement.  You might get them to agree on standards
that require very little code change.  You'd never get them to agree
on standards that would require their customers to change their code,
or on standards that preclude their implementation of `extra
features'.



Sun, 21 Aug 2005 00:02:09 GMT  
 Common Lisp Extensions (Was: UK lispers mailing list)

Quote:

> Right, there is indeed such a cost.  The amount a community can afford
> to spend on such efforts absent external funding depends on how large
> it is - people can, perhaps, spend 5% of their time or something doing
> free stuff.  So for the CL community, which is smaller than, say the
> C++ community, correspondingly less is done.  But not nothing -
> There are quasi-standard SQL bindings, foreign function call bindings
> and so on, aren't there?

Absolutely.  My point was that "the problem is money" did not tell the whole
story.

Matthias



Sun, 21 Aug 2005 00:06:07 GMT  
 
 [ 23 post ]  Go to page: [1] [2]

 Relevant Pages 

1. UK lispers mailing list

2. Is CMU Common Lisp available in the U.K. ?

3. Please remove dec@s-strat.co.uk from mailing list

4. Python-UK mailing list active again

5. UK mailing list

6. ANNOUNCE : mailing list for Python users in the UK

7. What I want from my Common Lisp vendor and the Common Lisp community

8. lucid common lisp -- C -- Common lisp intercallability

9. Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp - the Summary

10. Lucid (Sun) Common Lisp vs Allegro (Franz) Common Lisp

11. Sun Common Lisp vs. Allegro Common Lisp

12. UK-lispers, London pub-meet, thursday June 19th

 

 
Powered by phpBB® Forum Software