[cltl3-devel] requirements on CL libraries

[Stelian Ionescu]

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:
> 
> 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.

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.


> 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.

Yes


> 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 .

I agree, especially wrt. hierarchical packages and package locks.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090515/9d3ad698/attachment.sig>