cltl3-devel May 2009

cltl3-devel@common-lisp.net

8 participants
6 discussions

[cltl3-devel] CDR?
by Marco Antoniotti 19 May '09

19 May '09

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

2 1

[cltl3-devel] Some other suggestions
by Gustavo 17 May '09

17 May '09

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 mudballs<http://mudballs.com/>that 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-readtables<http://common-lisp.net/%7Etrittweiler/darcs/editor-hints/named-readtables/>is 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.

1 0

[cltl3-devel] Comments on recent mail
by Daniel Weinreb 16 May '09

16 May '09

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

3 2

[cltl3-devel] Fwd: Comments on recent mail
by Drew Crampsie 16 May '09

16 May '09

forgot to CC the list : ---------- Forwarded message ---------- From: Drew Crampsie <drewc(a)tech.coop> Date: 2009/5/16 Subject: Re: [cltl3-devel] Comments on recent mail To: Daniel Weinreb <dlw(a)alum.mit.edu> 2009/5/15 Daniel Weinreb <dlw(a)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 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(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel >

1 0

[cltl3-devel] requirements on CL libraries
by Peter Denno 15 May '09

15 May '09

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

4 4

[cltl3-devel] getting mindshare
by Nikodemus Siivola 15 May '09

15 May '09

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

cltl3-devel May 2009