cltl3-devel

cltl3-devel@common-lisp.net

23 discussions

Re: [cltl3-devel] RFC: CLtL3 Charter
by Gustavo 02 Sep '09

02 Sep '09

2009/9/1 Drew Crampsie <drew.crampsie(a)gmail.com> > 2009/9/1 Gustavo <gugamilare(a)gmail.com>: > > > > > > 2009/9/1 <drew.crampsie(a)gmail.com> > >> > >> I'd personally much prefer a 'lispy' (read : verbose and understandable) > >> implementation of regexps then the one from perl, and still wouldn't > want it > >> included as part of CLtL3.. > > > > cl-ppcre allow the use of sexps as regexps. I think that they are > "verbose" > > and "understandable". > > So it might ... but as per section 4 "Preference will be given to > topics that cannot be implemented portably and have multiple existing > implementations.". > I'm not saying that cl-ppcre should be made part of cltl3, I actually agree with you. That was just an off-topic comment (if someone doesn't know that already).

1 0

[cltl3-devel] Fwd: RFC: CLtL3 Charter
by Drew Crampsie 02 Sep '09

02 Sep '09

bloody list .. always forget to cc ---------- Forwarded message ---------- From: Drew Crampsie <drewc(a)tech.coop> Date: 2009/9/1 Subject: Re: [cltl3-devel] RFC: CLtL3 Charter To: Gustavo <gugamilare(a)gmail.com> 2009/9/1 Gustavo <gugamilare(a)gmail.com>: > > > 2009/9/1 Drew Crampsie <drewc(a)tech.coop> >> >> 2009/9/1 Gustavo <gugamilare(a)gmail.com>: >> > Hello, >> > >> > I also like to keep things simple. Here are a few suggestions, though. >> > >> > In paragraph 4, you didn't mention "sockets" explicitly in the list. I >> > don't >> > know if that is intended to be included in "Networking", because Unix >> > sockets are local to the computer. >> >> To be quite honest, i don't know if CLtL3 actually needs sockets or >> networking. If we have FFI and extensible streams, we can build >> sockets and networking as library code.. right? I'm interested in >> hearing dissent on this one. > > Well, yes, but all implementations that I know about have some interface to > sockets. So, I believe that this is a very small task for implementors, it > is just a matter of creating a small layer on top of them (like usocket) or > changing the functions that deal with them. Isn't Cltl3 meant to avoid the > need for portability layers? Yes, avoiding portability layers is a goal.. so when you state " it is just a matter of creating a small layer on top of them (like usocket)", we're directly against that goal. usocket and the like exist already, so there's not much value in working to standardize the interface... just use usocket! :) I'm not sure what you mean by 'changing the functions that deal with them' in this context, but a goal of cltl3 (i will add this to the charter) is to require as little effort on the part of implementors as possible. In the case of sockets and networking, we can provide library code from a single source... so why duplicate that effort across every distribution or implementation of lisp? Seems like a wasted effort and a barrier to adoption from my POV. It is possible, given FFI and gray streams, to implement sockets without using _any_ implementation defined socket code. Rather than a compatibility layer that attempts to paper over the differences in implementations (trouble with such layers being a large motivation for the creation of CLtL3), i'd prefer a single canonical implementation based on constructs provided by CLtL3. The prior art here (as for a lot of things we will be discussing) is IOlib. IOlib uses its own implementation of sockets and networking based on the OS's underlying implementation (through FFI). It is mostly portable and uniform across implementations, and does not require any support for networking in the implementation itself (fe[nl]ix had better correct me if i'm wrong). > Maybe we could make the support for sockets optional for each > implementation, but standardize the interface for sockets for > implementations that want to provide them (something like "These functions > may signal an error if the implementations doesn't have support for > sockets."). This is exactly what i'd like to avoid. If we have a portable implementation based on the simple constructs we plan to describe in CLtL3, we remove the need for implementors to support (or not support) our idea of what a socket library could be. We have no need to standardize an interface that implementors must support when we can write a portable interface. We can still call it 'standard' if you like, but 'standard library' and not 'cltl3', whatever that means :). CLtL3 should be for things that _cannot_ be implemented portably, first and foremost. Sockets and networking _can_ be, on operating system that support them, via FFI. The goal of CLtL3 is to create a lisp where it is possible to have portable networking code, but not necessarily to include that code in the language itself... The line between 'library' and 'base language' was heavily blurred during the ANSI process... i'd prefer not to repeat that (what i view as a) mistake. CL pathnames are the perfect example of what happens when you try to lowest-common-denominator these kind of things, and that's all we'd be able to do if we relied on existing implementation support. Going the other way, and expecting implementors and vendors to conform to our idea of what socket code should be is just as useless because, well, they won't. Simply asked : what exactly do we gain by requiring a socket and networking layer as part of the base language, as opposed to in the library we plan to build on that language? If all you want is a uniform API, a standard library will have that. Heck, if you want that, code against IOlib! I'm still not dismissing inclusion of networking and sockets, but i've not heard a convincing argument for them, and i think our time would be better spent elsewhere. [snipped bit about hash tables] > I believe that we could discuss it later, when we discuss the CDR documents > (we are going to do that, aren't we?). You bet. :) Cheers, drewc >> >> > (l) Weak Pointers, Weak Hashtables and Garbage Collector (like in >> > trivial-garbage). >> >> Right, i was just thinking about these last night. added. >> >> > And, by the way, "omission" have only one "m". >> >> Damnit... i've been spelling that word wrong my entire life and just >> found out now! thanks :) > > Thank my Firefox's spell checker :) > > One more suggestion: you could add this sentence or something similar (after > paragraph 4): > > "Other topics might be discussed in the course of the description, but > priority will be given to the topics mentioned above." > > This way we can choose to discuss lesser details later. > >> >> drewc > > > _______________________________________________ > cltl3-devel mailing list > cltl3-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel > >

1 0

[cltl3-devel] Fwd: RFC: CLtL3 Charter
by Gustavo 02 Sep '09

02 Sep '09

2009/9/1 <drew.crampsie(a)gmail.com> > > I'd personally much prefer a 'lispy' (read : verbose and understandable) > implementation of regexps then the one from perl, and still wouldn't want it > included as part of CLtL3.. > cl-ppcre allow the use of sexps as regexps. I think that they are "verbose" and "understandable".

1 0

[cltl3-devel] RFC: CLtL3 Charter
by Drew Crampsie 01 Sep '09

01 Sep '09

Hello all, Below is a draft of the charter for the CLtL3 project. Please comment as you see fit. Cheers, drewc Purposes of the CLtL3 effort. SECOND DRAFT - 2009-08-31 - 1) The CLtL3 group wishes to create an updated description of Common Lisp. It should codify existing practice and provide additional features to facilitate portability of code among diverse implementations. 2) The group intends the description to be a base for a larger "standard library" of code. The focus of the effort will be to provide library authors with a stable and portable lisp on which to build an evolving distribution that meets the ever changing needs of modern developers. 3) The group will begin with ANSI Common Lisp as described in the _Common Lisp Hyperspec_. All possible effort will be made to ensure source compatibility. The group does not intend to remove any functionality from the language, and will only deprecate features that are superseded by those in CLtL3. 4) The group will address the following topics in the course of producing the description. Preference will be given to topics that cannot be implemented portably and have multiple existing implementations. (a) Repairing mistakes, ambiguities, and minor ommissions in ANSI Common Lisp (b) Extensions outlined in the CDR (including the MOP) (c) Multiprocessing and Concurrency (d) Foreign Function Interfaces (e) Extensible Streams (f) Extensible Sequences (g) Networking (h) OS and Filesystem access (i) Editing and Introspection 5) The CLtL3 effort will be a community effort.Discussion will take place on public forums. Any source code or documents produced will be placed under a permissive open source license that also allows commercial use and redistribution.

3 2

[cltl3-devel] Fwd: RFC: CLtL3 Charter
by Gustavo 01 Sep '09

01 Sep '09

Sorry, drewc, the e-mail should have gone to the list, not only you. Hello, I also like to keep things simple. Here are a few suggestions, though. In paragraph 4, you didn't mention "sockets" explicitly in the list. I don't know if that is intended to be included in "Networking", because Unix sockets are local to the computer. A few more topics that could be discussed: (j) Interface to Environments, which is needed in a macro walker (e.g. cl-walker <http://common-lisp.net/project/cl-walker/> accesses lexical environments using implementation specific functions). (k)Custom Hash Functions and Hashtable Test (SBCL's extensions<http://www.sbcl.org/manual/Hash-Table-Extensions.html#Hash-Table-Extensions> ). (l) Weak Pointers, Weak Hashtables and Garbage Collector (like in trivial-garbage <http://www.cliki.net/trivial-garbage>). And, by the way, "omission" have only one "m". Cheers, Gustavo. 2009/8/31 Drew Crampsie <drewc(a)tech.coop> Hello all, > > Below is a draft of the charter for the CLtL3 project. Please comment > as you see fit. > > Cheers, > > drewc > > Purposes of the CLtL3 effort. SECOND DRAFT - 2009-08-31 - > > 1) The CLtL3 group wishes to create an updated description of Common > Lisp. It should codify existing practice and provide additional > features to facilitate portability of code among diverse > implementations. > > 2) The group intends the description to be a base for a larger "standard > library" of code. The focus of the effort will be to provide > library authors with a stable and portable lisp on which to build > an evolving distribution that meets the ever changing needs of > modern developers. > > 3) The group will begin with ANSI Common Lisp as described in the > _Common Lisp Hyperspec_. All possible effort will be made to ensure > source compatibility. The group does not intend to remove any > functionality from the language, and will only deprecate features > that are superseded by those in CLtL3. > > 4) The group will address the following topics in the course of > producing the description. Preference will be given to topics that > cannot be implemented portably and have multiple existing > implementations. > > (a) Repairing mistakes, ambiguities, and minor ommissions > in ANSI Common Lisp > (b) Extensions outlined in the CDR (including the MOP) > (c) Multiprocessing and Concurrency > (d) Foreign Function Interfaces > (e) Extensible Streams > (f) Extensible Sequences > (g) Networking > (h) OS and Filesystem access > (i) Editing and Introspection > > 5) The CLtL3 effort will be a community effort.Discussion will take > place on public forums. Any source code or documents produced will > be placed under a permissive open source license that also allows > commercial use and redistribution. > > _______________________________________________ > cltl3-devel mailing list > cltl3-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel >

1 0

[cltl3-devel] small proposal for listen function
by Shawn Betts 20 Jul '09

20 Jul '09

It'd be way cool if listen looked like this: (defun listen (timeout &rest streams) ...) and returned the list of streams that could be read from. -Shawn

2 1

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

18 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

cltl3-devel