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.