Hi,
I support the idea of developing a "standard" common lisp library. Doing so will provide common lisp with some of the capabilities that today's programmers expect. Here are some thoughts on the requirements that such an effort might address:
- A common style of presentation should be used across the parts of the library. This will reduce the effort required of the programmer to understand the purpose of the library, and how its capabilities may be interfaced to his program.
- There needs to be a common and simple means for programs to reference the library. Just to illustrate (not to suggest a solution) URLs might be used to reference parts of the library.
- There should be consistency as to how the parts load into the lisp program. There should be a lightweight interface for querying a program to determine what parts and versions thereof it contains.
- There needs to be an orderly "lifecycle process" to track and express the maturity of parts of the library.
- We should address the most important parts first. It is likely that there would be some debate as to what those parts are. My list includes regular expressions, XML handling, http and web page production, Relation DB interfacing. Note that there already is good code in all of these areas!
IMO, doing anything like this will require someone with the requisite abilities assume a "Project Editor" role -- responsible for development of most of the work products (specification of the interfaces to the parts, a guide to using the library, etc.). It would also require that some of the lisp community's top talent contribute with recommendations, text, and critique of the work products.
Hi
I don't want to sound negative... but this effort *must* be really taken lightly and ecumenically. If you can access the CLRFI/CLURFI logs, you will see that it is very easy to get into very heated fights. I know as I was one of the major offenders.
Yet I think I had some decent ideas about how to go ahead and "organize" extensions and categorize them. I will dig the proposal out as soon as I get to my other computer.
Cheers -- Marco
Peter Denno wrote:
Hi,
I support the idea of developing a "standard" common lisp library. Doing so will provide common lisp with some of the capabilities that today's programmers expect. Here are some thoughts on the requirements that such an effort might address:
- A common style of presentation should be used across the parts of
the library. This will reduce the effort required of the programmer to understand the purpose of the library, and how its capabilities may be interfaced to his program.
- There needs to be a common and simple means for programs to
reference the library. Just to illustrate (not to suggest a solution) URLs might be used to reference parts of the library.
- There should be consistency as to how the parts load into the lisp
program. There should be a lightweight interface for querying a program to determine what parts and versions thereof it contains.
- There needs to be an orderly "lifecycle process" to track and
express the maturity of parts of the library.
- We should address the most important parts first. It is likely that
there would be some debate as to what those parts are. My list includes regular expressions, XML handling, http and web page production, Relation DB interfacing. Note that there already is good code in all of these areas!
IMO, doing anything like this will require someone with the requisite abilities assume a "Project Editor" role -- responsible for development of most of the work products (specification of the interfaces to the parts, a guide to using the library, etc.). It would also require that some of the lisp community's top talent contribute with recommendations, text, and critique of the work products. --
Best regards,
- Peter Denno
cltl3-devel mailing list cltl3-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
On Fri, 2009-05-15 at 19:14 +0200, Marco Antoniotti wrote:
Hi
I don't want to sound negative... but this effort *must* be really taken lightly and ecumenically.
I agree.
If you can access the CLRFI/CLURFI logs, you will see that it is very easy to get into very heated fights. I know as I was one of the major offenders.
The original CRLFI archives were lost when the ALU site crashed, but are still available through archive.org
Yet I think I had some decent ideas about how to go ahead and "organize" extensions and categorize them. I will dig the proposal out as soon as I get to my other computer.
Excellent :)
Am 15.05.2009 um 18:17 schrieb Peter Denno:
Hi Peter,
Hi,
I support the idea of developing a "standard" common lisp library. Doing so will provide common lisp with some of the capabilities that today's programmers expect. Here are some thoughts on the requirements that such an effort might address:
...snipped...
- We should address the most important parts first. It is likely
that there would be some debate as to what those parts are. My list includes regular expressions, XML handling, http and web page production, Relation DB interfacing. Note that there already is good code in all of these areas!
I think such a project is certainly valuable to make common lisp more appealing for newbies - but I'm uncertain if it is really something for a CLtL3. Standardizing on implementations like "cl-ppcre" for regex, mel-base for email a. s. o. would really be the wrong thing. So one really could only standardize on interfaces: We could specify which interface an XML library, regex-library or mail library has to provide to be "CLtL3" compliant. Even that is not really what I hoped for with CLtL3, but certainly others may see that differently.
I would really like to see enhancements on five places:
1) [CLtL3-Streams] User-extensible streams For streams there is still the gray streams proposal - which is widely supported - and some new developments like Franz' simple-streams and the new streams interfaces of LispWorks. Things to look for are bivalent streams (good? bad?) unicode issues a. s. o.
2) [CLtL3-Sequences] User-extensible sequences AFAIR Christophe Rhodes wrote a paper about user extensible sequences. Being able to use functions like POSITION, ELT, MAP, SEARCH a.s.o on your own kinds of sequences.
3) [CLtL3-Hash-Tables] User-extensible hash tables There is a CDR for generic hash-tables. Most implementations support some extensions to specify a hash-function or some kinds of weakness.
4) [CLtL3-Environments] Environment Access for mortals In CLtL2 there were some facilities to access environments. Those didn't make it into the ANSI standard, but similar interfaces are supported by most CL systems. Franz made a proposal for an open interface for environment access.
5) [CLtL3-Packages] Enhancing package usefulness CL packages are a mighty tool. There have been ideas like hierarchical packages, package aliases and conduits to make managing packages easier. Most implementations support some kind of package locking which could make it into CLtL3-Packages. Another interesting issue would be making symbol case sensitivity a package property. At least CLISP supports such "case sensitive packages". It could be investigated how this could be a good idea or not .
ciao, Jochen
-- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9 , 90408 Nuremberg
Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83
mailto:info@crispylogics.com http://www.crispylogics.com
On Fri, 2009-05-15 at 19:40 +0200, Jochen Schmidt wrote:
Am 15.05.2009 um 18:17 schrieb Peter Denno:
Hi Peter,
Hi,
I support the idea of developing a "standard" common lisp library. Doing so will provide common lisp with some of the capabilities that today's programmers expect. Here are some thoughts on the requirements that such an effort might address:
...snipped...
- We should address the most important parts first. It is likely
that there would be some debate as to what those parts are. My list includes regular expressions, XML handling, http and web page production, Relation DB interfacing. Note that there already is good code in all of these areas!
I think such a project is certainly valuable to make common lisp more appealing for newbies - but I'm uncertain if it is really something for a CLtL3.
Yes, I agree. IMO Cltl3 is about updating the base language and library. XML, HTTP, SMTP etc ... could be taken care of in another project.
Standardizing on implementations like "cl-ppcre" for regex, mel-base for email a. s. o. would really be the wrong thing.
I don't think it would be so bad. We'd standardise an API, but having a reference implementation would be almost necessary.
So one really could only standardize on interfaces: We could specify which interface an XML library, regex-library or mail library has to provide to be "CLtL3" compliant. Even that is not really what I hoped for with CLtL3, but certainly others may see that differently.
I would really like to see enhancements on five places:
- [CLtL3-Streams] User-extensible streams
For streams there is still the gray streams proposal - which is widely supported - and some new developments like Franz' simple-streams and the new streams interfaces of LispWorks. Things to look for are bivalent streams (good? bad?) unicode issues a. s. o.
Bivalent streams are definitely good. User-extensible streams are necessary but not enough: sockets and a new interface for opening files and dealing with the filesystem are also necessary.
- [CLtL3-Sequences] User-extensible sequences
AFAIR Christophe Rhodes wrote a paper about user extensible sequences. Being able to use functions like POSITION, ELT, MAP, SEARCH a.s.o on your own kinds of sequences.
- [CLtL3-Hash-Tables] User-extensible hash tables
There is a CDR for generic hash-tables. Most implementations support some extensions to specify a hash-function or some kinds of weakness.
- [CLtL3-Environments] Environment Access for mortals
In CLtL2 there were some facilities to access environments. Those didn't make it into the ANSI standard, but similar interfaces are supported by most CL systems. Franz made a proposal for an open interface for environment access.
Yes
- [CLtL3-Packages] Enhancing package usefulness
CL packages are a mighty tool. There have been ideas like hierarchical packages, package aliases and conduits to make managing packages easier. Most implementations support some kind of package locking which could make it into CLtL3-Packages. Another interesting issue would be making symbol case sensitivity a package property. At least CLISP supports such "case sensitive packages". It could be investigated how this could be a good idea or not .
I agree, especially wrt. hierarchical packages and package locks.
-
Jochen Schmidt -
Marco Antoniotti -
Peter Denno -
Stelian Ionescu