[cltl3-devel] requirements on CL libraries

[Jochen Schmidt]

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 at crispylogics.com
http://www.crispylogics.com