From peter.denno at nist.gov Fri May 15 16:17:04 2009 From: peter.denno at nist.gov (Peter Denno) Date: Fri, 15 May 2009 12:17:04 -0400 Subject: [cltl3-devel] requirements on CL libraries Message-ID: <4A0D9580.1090102@nist.gov> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoniotti.marco at disco.unimib.it Fri May 15 17:14:11 2009 From: antoniotti.marco at disco.unimib.it (Marco Antoniotti) Date: Fri, 15 May 2009 19:14:11 +0200 Subject: [cltl3-devel] requirements on CL libraries In-Reply-To: <4A0D9580.1090102@nist.gov> References: <4A0D9580.1090102@nist.gov> Message-ID: <4A0DA2E3.1070904@disco.unimib.it> 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 at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: antoniotti_marco.vcf Type: text/x-vcard Size: 366 bytes Desc: not available URL: From js at crispylogics.com Fri May 15 17:40:58 2009 From: js at crispylogics.com (Jochen Schmidt) Date: Fri, 15 May 2009 19:40:58 +0200 Subject: [cltl3-devel] requirements on CL libraries In-Reply-To: <4A0D9580.1090102@nist.gov> References: <4A0D9580.1090102@nist.gov> Message-ID: 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 From nikodemus at random-state.net Fri May 15 17:49:15 2009 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Fri, 15 May 2009 20:49:15 +0300 Subject: [cltl3-devel] getting mindshare Message-ID: <633d72b0905151049t761c1313j1cbddf426432913b@mail.gmail.com> How does CLtL3 intend to get the mindshare it needs to succeed? I have a couple of ideas, but I'm asking because I assume this may have been discussed at ILC or elsewhere. My take: * Don't try to sell or do too much in a single go. Don't try to eg. build a massive system of classification for libraries before you have the libraries to classify. Don't try to sell MASSIVE ideas when you can get most of the way there with a few smaller ones. Decouple ideas initially. Let them aggregate only once they have acceptance and are implemented. * Remember to ask for what people *don't* want in addition to what they do want. This is not to say that controversial things cannot be done, but perhaps initial velocity (and trust in the projects ability to do its thing!) is best gained by focusing on the consensus. * Even if CL is a mudball of strength, I think what CLtL3 seems to aim at needs a razor sharp focus. Someone(tm) needs to keep the reigns tight and say "out of scope for now" to everything not in focus a the moment. Until a certain momentum is there focus is everything, I think. Cheers, and good luck! -- Nikodemus From stelian.ionescu-zeus at poste.it Fri May 15 20:17:49 2009 From: stelian.ionescu-zeus at poste.it (Stelian Ionescu) Date: Fri, 15 May 2009 22:17:49 +0200 Subject: [cltl3-devel] requirements on CL libraries In-Reply-To: References: <4A0D9580.1090102@nist.gov> Message-ID: <1242418669.3403.21.camel@blackhole.universe.org> 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: From stelian.ionescu-zeus at poste.it Fri May 15 20:27:02 2009 From: stelian.ionescu-zeus at poste.it (Stelian Ionescu) Date: Fri, 15 May 2009 22:27:02 +0200 Subject: [cltl3-devel] getting mindshare In-Reply-To: <633d72b0905151049t761c1313j1cbddf426432913b@mail.gmail.com> References: <633d72b0905151049t761c1313j1cbddf426432913b@mail.gmail.com> Message-ID: <1242419222.3403.30.camel@blackhole.universe.org> On Fri, 2009-05-15 at 20:49 +0300, Nikodemus Siivola wrote: > How does CLtL3 intend to get the mindshare it needs to succeed? I have > a couple of ideas, but I'm asking because I assume this may have been > discussed at ILC or elsewhere. By accepting everyone who's interested to partecipate. I think we can't do more than that: there's no DARPA now to threaten suspension of funding and force implementors to collaborate > My take: > > * Don't try to sell or do too much in a single go. Don't try to eg. > build a massive system of classification for libraries before you have > the libraries to classify. Don't try to sell MASSIVE ideas when you > can get most of the way there with a few smaller ones. Decouple ideas > initially. Let them aggregate only once they have acceptance and are > implemented. I think that Jochen's message summarized well the most important issues > * Remember to ask for what people *don't* want in addition to what > they do want. This is not to say that controversial things cannot be > done, but perhaps initial velocity (and trust in the projects ability > to do its thing!) is best gained by focusing on the consensus. I agree > * Even if CL is a mudball of strength, I think what CLtL3 seems to aim > at needs a razor sharp focus. Someone(tm) needs to keep the reigns > tight and say "out of scope for now" to everything not in focus a the > moment. Until a certain momentum is there focus is everything, I > think. I agree > Cheers, and good luck! thanks :) -- 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: From stelian.ionescu-zeus at poste.it Fri May 15 20:50:36 2009 From: stelian.ionescu-zeus at poste.it (Stelian Ionescu) Date: Fri, 15 May 2009 22:50:36 +0200 Subject: [cltl3-devel] requirements on CL libraries In-Reply-To: <4A0DA2E3.1070904@disco.unimib.it> References: <4A0D9580.1090102@nist.gov> <4A0DA2E3.1070904@disco.unimib.it> Message-ID: <1242420636.3403.54.camel@blackhole.universe.org> 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 :) -- 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: From dlw at alum.mit.edu Sat May 16 02:55:45 2009 From: dlw at alum.mit.edu (Daniel Weinreb) Date: Fri, 15 May 2009 22:55:45 -0400 Subject: [cltl3-devel] Comments on recent mail Message-ID: <4A0E2B31.5050602@alum.mit.edu> Here are my opinions on the issues discussed in the recent mail. Nikodemus's points are excellent. For this effort to succeed, it must start small. I also agree that it should be bottom-up. It should start with existing, accepted libraries, and avoid innovation: experience has shown that it's usually unwise to standardize things that haven't been tried out pretty thoroughly. I'm sympathetic with what Peter Denno says, but I've been though things like this before, and trying to "do the right thing" from the beginning, in a project such as this one, often ends up stopping the whole thing from happening. We should start pulling things together, and then try to move towards the more careful, professional practices that Peter describes. Jochen brings up the question of whether we want to standardize on official interfaces only, or on implementations as well. CLtL itself attempted to describe all the functions, macros, etc. without saying anything about their implementation. Here, there may be some conceptual tension between whether we are trying to define (more or) a langauge, establish a set of API's to libraries without saying anything about their implementation, or gather a useful common set of libraries. The Manifesto talks about "language extensions" at one point, and a "standard library" later on, which may lead to some confusion about this point. On the other hand, if you look at CLtL, you can see that it does not separate a "core language" from a bunch of functions and macros that can be build on that core language. (That's a big reason that Common Lisp is criticized as being a language that's "too large". If you consider Java plus all the standard Java libraries, it looks big too!) We had originally wanted to define CLtL that way, but it was too difficult, for many practical reasons. So Common Lisp is left with a legacy of not distinguishing clearly between what is the "language" and what are "already-loaded standard libraries". This leads into the question of scope. There are some things that are so basic, and so widely needed, and so small, that it's completely clear that they belong: a library for portable sockets (usocket), for example. A way to write one's own streams is clearly a language extension, and one of the various stream packages should certainly be included. It would be great to be able to have a standard way to deal with Unicode strings, although there are some thing that made that hard. Thread manipulation is another obvious candidate. Then you can move up to thinks that are quite clearly libraries, yet considered something that any system should not be without, such as regular expressions. Then there are XML libraries, an HTTP client, an HTTP server. There are some things where it's not clear what approach is best, such as generation of web pages and interfacing to relational databases, but we could pick one. What I, myself, would like to see is easy ways for programmers to do all the normal things that application programs and servers can do today. How much of that belongs in the scope of the CLtL3 process is yet to be determined. We might agree that there should be easy and common ways to do an HTTP server, but also agree that CLtL3 isn't the place to put them. Sequences, along the lines that Christope Rhodes has started to do, would be great. On the other hand, I think what he has so far isn't ideal and needs more development, and I'd be hesitant about declaring it a standard at this point. New ideas on packages and modules, while welcome, are something I'd consider too innovative to put into a "standard" library. These thing are hard to invent and take a long time to get experience with. I was one of the people who designed packges (yes, mea culpa) and I've been involved more than once in trying to come up with better modularity constructs, and I can assure you it's not obvious or easy. Let's stick to what's well-understood for the foreseeable future. -- Dan -- ________________________________________ Daniel Weinreb http://danweinreb.org/blog/ Discussion about the future of Lisp: ilc2009.scheming.org From js at crispylogics.com Sat May 16 04:44:48 2009 From: js at crispylogics.com (Jochen Schmidt) Date: Sat, 16 May 2009 06:44:48 +0200 Subject: [cltl3-devel] Comments on recent mail In-Reply-To: <4A0E2B31.5050602@alum.mit.edu> References: <4A0E2B31.5050602@alum.mit.edu> Message-ID: <8A8E394D-7FAF-4F86-A3B1-50F7806E07AF@crispylogics.com> Am 16.05.2009 um 04:55 schrieb Daniel Weinreb: > The Manifesto talks about "language extensions" at one point, and a > "standard library" later on, which may lead to some confusion about > this point. On the other hand, if you look at CLtL, you can see that > it does not separate a "core language" from a bunch of functions and > macros that can be build on that core language. (That's a big reason > that Common Lisp is criticized as being a language that's "too large". > If you consider Java plus all the standard Java libraries, it looks > big too!) We had originally wanted to define CLtL that way, but it > was too difficult, for many practical reasons. So Common Lisp is left > with a legacy of not distinguishing clearly between what is the > "language" and what are "already-loaded standard libraries". Yes thats true - but isn't this an even bigger reason to be more careful for CLtL3? I think it might be interesting to split the effort into a CLtL3 Core and CLtL3 Extensions. In CLtL3 Extensions many more things are allowed, it is a place for experimentation. Proven things may later get included into the CLtL3 Core. At this stage we can start collecting things and start picking pearls when there is enough on the table. > > This leads into the question of scope. There are some things that are > so basic, and so widely needed, and so small, that it's completely > clear that they belong: a library for portable sockets (usocket), for > example. A way to write one's own streams is clearly a language > extension, and one of the various stream packages should certainly be > included. It would be great to be able to have a standard way to deal > with Unicode strings, although there are some thing that made that > hard. Thread manipulation is another obvious candidate. The real problem is that for nearly all things like threads or sockets there is a huge difference in what people demand. Some people want strict Unix semantics others just want something simple. Some features may not be easily done in a platform independent way. The problem is here to how to decide what we want to settle on. There needs to be a clear process. Language extensions are another problem. While every language user can write an XML-Parser to a specified interface, it isn't that easy to extend a closed vendors lisp with things like e.g. user extensible streams. How do we want to get vendors involved? Without vendor support CLtL3 will only be just another paper tiger. > Then you can move up to thinks that are quite clearly libraries, yet > considered something that any system should not be without, such as > regular expressions. Then there are XML libraries, an HTTP client, an > HTTP server. There are some things where it's not clear what approach > is best, such as generation of web pages and interfacing to relational > databases, but we could pick one. I think concentrating on this would scatter the effort too much at this point. While I find things like XML-Libraries (cxml) or regular expressions (cl-ppcre) relatively straightforward to decide - how would we want to choose a HTTP Server? CL-HTTP? AllegroServe? Hunchentoot? UCW? Araneida? I think there is nothing wrong collecting data about available options and evaluate them. > > What I, myself, would like to see is easy ways for programmers to do > all the normal things that application programs and servers can do > today. How much of that belongs in the scope of the CLtL3 process is > yet to be determined. We might agree that there should be easy and > common ways to do an HTTP server, but also agree that CLtL3 isn't the > place to put them. Yes > > Sequences, along the lines that Christope Rhodes has started to do, > would be great. On the other hand, I think what he has so far isn't > ideal and needs more development, and I'd be hesitant about declaring > it a standard at this point. Sequences have a long way to go - I don't know if there is any reference implementation yet. If there is one it exists probably only for one implementation. But I still think it is a perfect candidate for CLtL3 Extensions. > > New ideas on packages and modules, while welcome, are something I'd > consider too innovative to put into a "standard" library. These thing > are hard to invent and take a long time to get experience with. I was > one of the people who designed packges (yes, mea culpa) and I've been > involved more than once in trying to come up with better modularity > constructs, and I can assure you it's not obvious or easy. Let's > stick to what's well-understood for the foreseeable future. I guess you mean CL packages and not ASDF, DEFSYSTEM a.s.o. Hierarchical packages do exist for quite some time on many different implementations. I personally do like the idea of Tim Bradshaws conduits package better; particularily per-package aliases. With the latter you can specify nicknames for other packages in your own packages without changing the package names or nicknames globally. The conduits system is severals years old and I think of it as a proven thing. I think there should be some discussion if something of this could make it into CLtL3. Tim Bradshaw's Conduits: http://www.tfeb.org/lisp/hax.html#CONDUITS 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 From drewc at tech.coop Sat May 16 20:56:00 2009 From: drewc at tech.coop (Drew Crampsie) Date: Sat, 16 May 2009 13:56:00 -0700 Subject: [cltl3-devel] Fwd: Comments on recent mail In-Reply-To: References: <4A0E2B31.5050602@alum.mit.edu> Message-ID: forgot to CC the list : ---------- Forwarded message ---------- From: Drew Crampsie Date: 2009/5/16 Subject: Re: [cltl3-devel] Comments on recent mail To: Daniel Weinreb 2009/5/15 Daniel Weinreb : > Here are my opinions on the issues discussed in the recent mail. > > Nikodemus's points are excellent. ?For this effort to succeed, it must > start small. ?I also agree that it should be bottom-up. ?It should > start with existing, accepted libraries, and avoid innovation: > experience has shown that it's usually unwise to standardize things > that haven't been tried out pretty thoroughly. I agree 100% with both Nikodemus and yourself on this point. We have to start small and actually achieve something rather than aim for the stars. > Jochen brings up the question of whether we want to standardize on > official interfaces only, or on implementations as well. ?CLtL itself > attempted to describe all the functions, macros, etc. without saying > anything about their implementation. ?Here, there may be some > conceptual tension between whether we are trying to define (more or) a > langauge, establish a set of API's to libraries without saying > anything about their implementation, or gather a useful common set of > libraries. Gathering a useful common set of libraries is a good start, but it's not enough. I'm going to use CLOS and LOOP of examples of things that could simply have been part of a collection of libraries, but were rather made 'part of the language', and the language is better for it (imo). I personally think the best approach (for a start) is to establish a set of API's based on existing libraries, and work to document and integrate these extensions. > The Manifesto talks about "language extensions" at one point, and a > "standard library" later on, which may lead to some confusion about > this point. This was intentional, as i see CLtL3 as both a core language, and a set of 'standard' libraries that use the core language. Something like Hunchentoot obviously does not belong in the core language, but it does require threads and sockets and extensible streams and unicode and ffi to function properly. I can see some value in distributing a set of libraries that are known to work together and all use the cltl3 versions of (threads sockets ffi etc) rather than the various existing libraries. This is not, however, an immediate goal of mine. > On the other hand, if you look at CLtL, you can see that > it does not separate a "core language" from a bunch of functions and > macros that can be build on that core language. ?(That's a big reason > that Common Lisp is criticized as being a language that's "too large". > If you consider Java plus all the standard Java libraries, it looks > big too!) ?We had originally wanted to define CLtL that way, but it > was too difficult, for many practical reasons. ?So Common Lisp is left > with a legacy of not distinguishing clearly between what is the > "language" and what are "already-loaded standard libraries". I think it will be useful to define a CLtL3 core distinct from the 'standard library' of code that runs on top of it. This core already includes ANSI CL, of course, + the language extenstions we can agree on. > This leads into the question of scope. ?There are some things that are > so basic, and so widely needed, and so small, that it's completely > clear that they belong: a library for portable sockets (usocket), for > example. ?A way to write one's own streams is clearly a language > extension, and one of the various stream packages should certainly be > included. ?It would be great to be able to have a standard way to deal > with Unicode strings, although there are some thing that made that > hard. ?Thread manipulation is another obvious candidate. I think that we can all agree that sockets, threads, streams, FFI and unicode are all in scope. I'd like to throw environment access on the pile (can't write a portable code-walker without it). > > What I, myself, would like to see is easy ways for programmers to do > all the normal things that application programs and servers can do > today. ?How much of that belongs in the scope of the CLtL3 process is > yet to be determined. ?We might agree that there should be easy and > common ways to do an HTTP server, but also agree that CLtL3 isn't the > place to put them. I think it might be useful to define 3 different 'scopes', Core, Experimental and Library (and possibly a fourth, 'Contrib', after we ship and people build on that). Obviously, we should initially focus on Core, but i think that, having all these minds together, we shouldn't stop there :). > > Sequences, along the lines that Christope Rhodes has started to do, > would be great. ?On the other hand, I think what he has so far isn't > ideal and needs more develop'ment, and I'd be hesitant about declaring > it a standard at this point. I'd like to see extensible sequences in CL, but i can agree that without being widely used, something shouldn't be standard. The CLtL3 'Experimental' scope is perfect for such things... a 'Library' should feel free to use things in Experimental, as both Experimental and Library will be specified as unstable interfaces. > New ideas on packages and modules, while welcome, are something I'd > consider too innovative to put into a "standard" library. ?These thing > are hard to invent and take a long time to get experience with. ?I was > one of the people who designed packges (yes, mea culpa) and I've been > involved more than once in trying to come up with better modularity > constructs, and I can assure you it's not obvious or easy. ?Let's > stick to what's well-understood for the foreseeable future. I agree with you on the last point.. we have to keep it simple and stick to what we know, at least initially. Once we've gained some traction, and things in 'Experimental' are being used, that will hopefully lead to the experimentation and discussion that is needed to improve and eventually 'standardise' such things. Until that point, we should make sure that we are simply describing and gathering current best practices. One of my first 'deliverables' for this project is a "CLtL3 Charter" along the lines of the x3j13 charter ( http://www.nhplace.com/kent/CL/x3j13-sd-05.html ). I think it will help immensely to have a document to point at and say 'this is what we're doing and how we're doing it'. If we can come to a reasonable consensus on the initial focus of CLtL3, that would go a long way towards defining a charter :). Cheers, drewc > > -- Dan > > -- > ________________________________________ > Daniel Weinreb > http://danweinreb.org/blog/ > Discussion about the future of Lisp: ilc2009.scheming.org > > > > > _______________________________________________ > cltl3-devel mailing list > cltl3-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel > From drewc at tech.coop Sat May 16 20:57:02 2009 From: drewc at tech.coop (Drew Crampsie) Date: Sat, 16 May 2009 13:57:02 -0700 Subject: [cltl3-devel] Comments on recent mail In-Reply-To: <8A8E394D-7FAF-4F86-A3B1-50F7806E07AF@crispylogics.com> References: <4A0E2B31.5050602@alum.mit.edu> <8A8E394D-7FAF-4F86-A3B1-50F7806E07AF@crispylogics.com> Message-ID: 2009/5/15 Jochen Schmidt : > > Am 16.05.2009 um 04:55 schrieb Daniel Weinreb: > >> The Manifesto talks about "language extensions" at one point, and a >> "standard library" later on, which may lead to some confusion about >> this point. ?On the other hand, if you look at CLtL, you can see that >> it does not separate a "core language" from a bunch of functions and >> macros that can be build on that core language. ?(That's a big reason >> that Common Lisp is criticized as being a language that's "too large". >> If you consider Java plus all the standard Java libraries, it looks >> big too!) ?We had originally wanted to define CLtL that way, but it >> was too difficult, for many practical reasons. ?So Common Lisp is left >> with a legacy of not distinguishing clearly between what is the >> "language" and what are "already-loaded standard libraries". > > Yes thats true - but isn't this an even bigger reason to be more > careful for CLtL3? I think it might be interesting to split the effort > into a CLtL3 Core and CLtL3 Extensions. In CLtL3 Extensions many more > things are allowed, it is a place for experimentation. Proven things > may later get included into the CLtL3 Core. At this stage we can start > collecting things and start picking pearls when there is enough on the > table. This is in line with my thoughts as well. > >> >> This leads into the question of scope. ?There are some things that are >> so basic, and so widely needed, and so small, that it's completely >> clear that they belong: a library for portable sockets (usocket), for >> example. ?A way to write one's own streams is clearly a language >> extension, and one of the various stream packages should certainly be >> included. ?It would be great to be able to have a standard way to deal >> with Unicode strings, although there are some thing that made that >> hard. ?Thread manipulation is another obvious candidate. > > The real problem is that for nearly all things like threads or sockets > there is a huge difference in what people demand. Some people want > strict Unix semantics others just want something simple. Some features > may not be easily done in a platform independent way. The problem is > here to how to decide what we want to settle on. There needs to be a > clear process. Indeed .. deciding what to 'settle on', as you put it, is going to be the biggest problem we face initially. My hope is that we, as a group, can reach a reasonable consensus after some (likely heated) discussion. In the end, just choosing something and going for it will be significantly more productive then waiting for the perfect solution. CLtL3 will not be frozen in time and impossible to update like ANSI, it will be a fluid proccess and a continually growing language. I believe this is what the original intent behind the original CL efforts, and i'd very much like to see modern CL in line with the original design goals. Worse is better, especially when the other option is 'nothing'. :) > > Language extensions are another problem. While every language user can > write an XML-Parser to a specified interface, it isn't that easy to > extend a closed vendors lisp with things like e.g. user extensible > streams. How do we want to get vendors involved? Without vendor > support CLtL3 will only be just another paper tiger. By beginning with (mostly) portable language extensions, we don't initially have to care about vendors. If a certain lisp doesn't support a feature we need, then that lisp is not CLtL3 compatible... this is not a big deal, it's not like we're ANSI. I don't expect the CLtL3 project to even be a blip on the radar of a commercial implementor, as most of them they already ship a CLtL3-like lisp. If their customers start demanding CLtL3 compatibility, we've already won. As for the open source lisps... well, the solution is obvious. We write code. >> Then you can move up to thinks that are quite clearly libraries, yet >> considered something that any system should not be without, such as >> regular expressions. ?Then there are XML libraries, an HTTP client, an >> HTTP server. ?There are some things where it's not clear what approach >> is best, such as generation of web pages and interfacing to relational >> databases, but we could pick one. > > I think concentrating on this would scatter the effort too much at > this point. While I find things like XML-Libraries (cxml) or regular > expressions (cl-ppcre) relatively straightforward to decide - I'd just like to point out that Edi himself would be against 'standardising' CL-PPCRE. The design goals of CL-PPCRE were not to create a most excellent lispy implementation of regexps, but to try and do a better PERL-compatible regexp engine than Perl. >> Sequences, along the lines that Christope Rhodes has started to do, >> would be great. ?On the other hand, I think what he has so far isn't >> ideal and needs more development, and I'd be hesitant about declaring >> it a standard at this point. > > Sequences have a long way to go - I don't know if there is any > reference implementation yet. If there is one it exists probably only > for one implementation. But I still think it is a perfect candidate > for CLtL3 Extensions. SB-SEQUENCE is the reference implementations, and i agree with your 'extensions' proposal. >> >> New ideas on packages and modules, while welcome, are something I'd >> consider too innovative to put into a "standard" library. ?These thing >> are hard to invent and take a long time to get experience with. ?I was >> one of the people who designed packges (yes, mea culpa) and I've been >> involved more than once in trying to come up with better modularity >> constructs, and I can assure you it's not obvious or easy. ?Let's >> stick to what's well-understood for the foreseeable future. > > I guess you mean CL packages and not ASDF, DEFSYSTEM a.s.o. > Hierarchical packages do exist for quite some time on many different > implementations. I personally do like the idea of Tim Bradshaws > conduits package better; particularily per-package aliases. With the > latter you can specify nicknames for other packages in your own > packages without changing the package names or nicknames globally. > The conduits system is severals years old and I think of it as a > proven thing. I think there should be some discussion if something of > this could make it into CLtL3. I like conduits as well, and a few lisps also have hierarchal packages now as well. I think that the package system is worth re-visiting (sorry dan!), and simple extensions like conduits are a good start.. I can see uses for cloned packages and the like within CLtL3 itself. Keep the great ideas and discussion coming! Cheers, drewc > > Tim Bradshaw's Conduits: > http://www.tfeb.org/lisp/hax.html#CONDUITS > > 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 > > > _______________________________________________ > cltl3-devel mailing list > cltl3-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel > From gugamilare at gmail.com Sun May 17 02:22:08 2009 From: gugamilare at gmail.com (Gustavo) Date: Sat, 16 May 2009 23:22:08 -0300 Subject: [cltl3-devel] Some other suggestions Message-ID: <4be8713d0905161922x5eb1211av8a92d6141d9e5267@mail.gmail.com> Hello, everyone, CL could use a new standard, specially in the area of threads, FFI, sockets, extensible streams (Gray or Simple streams), Unicode support and perhaps also MOP. It would be nice to see something like a transaction model for better thread support. There are also a few ideas that I would like to share. One thing is declarations for "static-ness". For instance, suppose that you have a generic function which you won't add any new methods to and that you will not change any method of this generic function. So you should be able to optimize its call by declaring it static. Same thing could be done to a class (and freeze subtypes / slots), to a type declaration or to a normal function (don't know if it is usefull to do this to function as I am no compiler writer). Well, I wouldn't object if this is not standardized, it is just a simple idea. The system definition also needs to be standardized. And I would say something better than ASDF. There is a project called mudballsthat has some neat features. How about making it possible to download projects in a similar way to how you install software in Linux (you put addresses of the repositories in a configuration file, then call a function that downloads and compiles packages)? Another neat feature: every package having its own readtable, which can be changed and copied to another package. It would avoid ugly workarounds to make readmacros portable (like cl-sql uses). named-readtablesis a good example of how this can be done. I would also like to state that backward compatibility should be taken into account and thinking not only twice, but at least three or four times before doing things in an incompatible way. We don't have enough programmers to rewrite every library that has already been written in CL, and just lose them all would be a shame. And last, one thing that could be better in implementations is the hability to make smaller programs. I believe that ECL is the best implementation when it comes to RAM usage or to distribute small programs - you can write a bunch of programs and compile them into small executable which depends on a pretty much small dynamic library. Implementations that save the lisp image won't do as good as this for obvious reasons, but, how about separating cl function into modules (a module for sequence manipulation, another module for pretty printing, another module with CLOS...) and make those modules unloadable? This way you can unload unnecessary modules to your program before dumping the core image. Well, this idea may be a little tricky to be actually done, so this probably should be left for a distant future, if ever. You all can count on me to do some of the coding. And to give some opinion as well :) Gustavo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoniotti.marco at disco.unimib.it Mon May 18 14:44:33 2009 From: antoniotti.marco at disco.unimib.it (Marco Antoniotti) Date: Mon, 18 May 2009 16:44:33 +0200 Subject: [cltl3-devel] CDR? Message-ID: <445B1142-E815-41B7-998D-02095EE6B1F7@disco.unimib.it> Hi I went through the old mail and stuff and found the old CLRFI things. Of that, I would salvage a few things, although a lot of it would fit in the "too big" category. But before going on, I'd like to raise the issue: why not the CDR as is? Maybe spruce it up with a nice wiki and whatnot, but why something different? Cheers -- Marco ELS 2009 www.european-lisp-symposium.org From stelian.ionescu-zeus at poste.it Mon May 18 23:25:21 2009 From: stelian.ionescu-zeus at poste.it (Stelian Ionescu) Date: Tue, 19 May 2009 01:25:21 +0200 Subject: [cltl3-devel] CDR? In-Reply-To: <445B1142-E815-41B7-998D-02095EE6B1F7@disco.unimib.it> References: <445B1142-E815-41B7-998D-02095EE6B1F7@disco.unimib.it> Message-ID: <1242689122.4529.187.camel@blackhole.universe.org> On Mon, 2009-05-18 at 16:44 +0200, Marco Antoniotti wrote: > Hi > > I went through the old mail and stuff and found the old CLRFI things. > Of that, I would salvage a few things, although a lot of it would fit > in the "too big" category. > > But before going on, I'd like to raise the issue: why not the CDR as is? > Maybe spruce it up with a nice wiki and whatnot, but why something > different? Because that's not enough: I want to have a single repository containing a reference implementation of all issues discussed, with a test suite and documentation. The repository would create a single package named :CLTL3(for starters) which re-exports CL symbols - eventual shadowing + all new symbols. Given a large task such as coming up with a new API for streams, pathnames and OS interface, having an implementation to play with is necessary: the API would be too large to just think about it and would require hands-on testing in order to be fully understood. The repository should also use ASDF(for the moment at least) so that I(and other brave people) can use it in personal projects and use :CLTL3 instead of :CL Also, I don't like the idea of having a period of only 6 weeks(or even months) during which a proposal can be modified: it's not enough. Consider for how long was CLTL2 discussed and how implementors still run into under- and un-specified behaviour(see a sample at http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications) -- 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: