September 2009 - cltl3-devel@lists.common-lisp.net

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

28 Sep '09

did it again .. somebody smack me upside the head! ---------- Forwarded message ---------- From: Drew Crampsie <drew.crampsie(a)gmail.com> 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(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.". There will be a library folks, and that is what you as a coder will likely use. CLtL3 is not for coders, but for implementors and library authors (who, yes, are also coders but you get the idea). It's for things we can't currently do in portable common lisp, not for things that have been done and already see wide use. There is nothing holding back the acceptance of cl-ppcre as the 'standard' portable implementation of perl compatible regular expressions, so why waste time documenting and discussing it? It will take an incredible amount of effort to describe in any detail the interface of cl-ppcre, and for little to no gain. When a new perl comes out, do we go ahead and change the standard? do we freeze cl-ppcre at the time we publish CLtL3? I understand that what a lot of people want is a 'standard library', and not an updated description. I'd like that too. But we have to get there somehow, and as it stands we cannot build our 'standard library' on Standard Common Lisp. That is what CLtL3 is trying to fix. Cheers, drewc >

3 3

Re: [cltl3-devel] RFC: CLtL3 Charter
by drew.crampsie＠gmail.com 14 Sep '09

14 Sep '09

2009/9/1 Ian Mondragon <ian.mondragon(a)gmail.com>: > I'll second (or third?) the appreciation of the simplicity. > Two questions though: > 1. What exactly does "Editing" in (i) imply? I could guess (esp. with it > being lumped with "Introspection"), but I'll hold off on assuming > things... Basically I'm thinking of the the functionality used by SLIME here.. things like source-location (for M-.) and the who-calls introspection etc. If someone has better wording for (i), please speak up. > 2. While the "OS and Filesystem access" point is one I'm especially keen > on, > I'd like to hear what anyone's opinion would be on CLTL3 standardized > regex > functionality Absolutely not :). > Mr. Weitz's cl-ppcre seems to be fairly widely used & may be > the *de-facto* standard, but why not take it one step further? I think the better question is 'why take it further'? Personally, i don't use regexps that much, so i'm biased.. but... Is the PERL regexp standard the one we'd like to follow? There is a perfectly good portable implementation that is an excellent candidate for inclusion in the 'standard library', so why would CLtL3 need to include its own description of a defacto standard from another language? 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.. regexps are not simple, and can be implemented without implementation support, so there is no good reason to include them in the base language. Should we also include cl-awk? How about an infix macro? an SQL syntax library? A parser generator? why cl-ppcre over any of those? Edi himself has spoken against the idea of 'standardising' on cl-ppcre (i can't find the reference right now), and IIRC his reasoning was similar to mine. So, to turn the question around, how would including cl-ppcre help meet the goals of the project as outlined in the charter? Again, i'll be your devil's advocate for the duration of these discussions, so please don't assume i'm dismissing this outright... but the questions and reasoning behind my arguments are valid... so i'd love to hear counter-arguments. Just to give you some ammo, ANSI included FORMAT and LOOP, and similar arguments could have been (and were) made against them. Cheers, drewc On Sep 1, 2009 12:43pm, Drew Crampsie <drewc(a)tech.coop> wrote: > 2009/9/1 Ian Mondragon ian.mondragon(a)gmail.com>: > > I'll second (or third?) the appreciation of the simplicity. > > > > Two questions though: > > > > 1. What exactly does "Editing" in (i) imply? I could guess (esp. with it > > being lumped with "Introspection"), but I'll hold off on assuming > things... > Basically I'm thinking of the the functionality used by SLIME here.. > things like source-location (for M-.) and the like. > If someone has better wording for (i), please speak up. > > 2. While the "OS and Filesystem access" point is one I'm especially > keen on, > > I'd like to hear what anyone's opinion would be on CLTL3 standardized > regex > > functionality > Absolutely not :). > > Mr. Weitz's cl-ppcre seems to be fairly widely used & may be > > the *de-facto* standard, but why not take it one step further? > I think the better question is 'why take it further'? Personally, i don't > use regexps that much, so i'm biased.. but... > Is the PERL regexp standard the one we'd like to follow? There is a > perfectly good portable implementation that is an excellent candidate for > inclusion in the 'standard library', so why would CLtL3 need to include > its own description of a defacto standard from another language? > 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.. regexps are not simple, and can be > implemented without implementation support, so there is no good reason to > include them in the base language. > Should we also include cl-awk? How about an infix macro? an SQL syntax > library? A parser generator? why cl-ppcre over any of those? > Edi himself has spoken against the idea of 'standardising' on cl-ppcre (i > can't find the reference right now), but IIRC his reasoning was similar > to mine. > So, to turn the question around, how would including cl-ppcre help meet > the goals of the project as outlined in the charter? > Again, i'll be your devil's advocate for the duration of these > discussions, so please don't assume i'm dismissing this > > > > Just food for thought. > > > > :ian > > > > On Mon, Aug 31, 2009 at 2:57 PM, Drew Crampsie drewc(a)tech.coop> wrote: > >> > >> 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 > > > >

4 3

[cltl3-devel] wishlist items
by Daniel Herring 08 Sep '09

08 Sep '09

Here are a few items on my post-ANSI wishlist. Please forgive me if I'm not following proper CLtL3 wishlist protocol. * Get REQUIRE right. IIRC, CLtL2 had *MODULE-PROVIDER-HOOKS*. This is good. There should be a standard way for defsystems to coexist. * If versioning semantics are added to REQUIRE, I suggest something like - (require system &optional version), NIL matches any version - require signals an error if the requested version doesn't match a currently loaded version - versions have three numbers (a la libtool) - "major" number represents external API changes (e.g. new functions) - "minor" number represents internal changes (e.g. bugfixes) - "range" counts minor numbers that are binary compatible - Example: 5.7.2 - API 5, release 7, backwared compatible with 5.6.x and 5.5.x - projects compiled against 1.x.y-4.x.y will need to be recompiled and may also need code changes - projects compiled against 5.0.x-5.4.x will require a recompile but no code changes * Standardize read macros that dispatch on a symbol. The current read-macro namespace is too crowded. Here are a couple syntax variants. The first lets the dispach function read everything; it takes the current standard read-macro arguments. The second uses a normal read to get the default arguments; it takes the read-macro arguments as special variables. - #?(read-if (= 1 2) :true :false) dispatch to #'read-if which reads "(= 1 2)", skips :true, and reads :false - #!(read-if nil)(:true :false) dispatch to (read-if nil), which skips :true and reads :false * Allow packages to specify whether they want case folding. The ANSI CL reader folds case first, then looks for a match. I'm aware of a few skunkworks projects which try to reverse that order. Thus CL::REQUIRE will always fold case, but symbols in package PR could have their case preserved. * Provide a standard code walker. * Define a standard mapping between pathnames and files on the major OSs. * Split CL into smaller packages like CL.ALIST, CL.PLIST, etc. Use symbol macros for symbols in CL. * Provide a standard way for macros to query type-inferencing info, declarations, etc. * Introduce a range api, and use it as a standard way to hook any datastructure into MAP*, NTH, etc. Something like Clojure or D. http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html * Define CL's memory model in a multithreaded environment, a la JSR133. http://jcp.org/en/jsr/detail?id=133 Later, Daniel

4 4

[cltl3-devel] Pathnames
by Marco Antoniotti 07 Sep '09

07 Sep '09

... just to start a bit of a flame war :), I submit here that a good start to solve the pathname issue is my very own NAMES-AND-PATHS effort. http://common-lisp.net/project/names-and-paths/ I also have code that implements a lot of the syntax. Comments and developers welcome. ... and no: symlinks (a UNIX concept and one of the problems that newbies find with ASDF) are explicitely not handled. Cheers -- Marco Antoniotti

1 0

Re: [cltl3-devel] RFC: CLtL3 Charter
by John Fremlin 07 Sep '09

07 Sep '09

It's awesome that the standard is getting revisited. In my view there are four main problem areas. I think it's most important that the broken or lacking core language features be addressed! Other languages have groups continually going over these things; Common Lisp needs one too. (1) Missing or broken language features that should be added or fixed Crummy type-system (at least parameterised types please)! As Levente also brought up: also access to type inference, etc. This would allow: Efficient generic functions dispatched to inline expansions at compile time. Value semantics. More help for code walkers and transformers (what does a declare form refer to?, etc.) Limited(?) serialisation of closures. Ability to locally alias a symbol and package (2) Brokenness in the current Lisp standard Different facilities should be separated and put into different packages. Pathnames are overly complicated and do not handle symlinks well. Extensible sequences, gray streams, etc. Hash-tables should be generalised like extensible sequences allow user implementation of other datastructures. eq, eql, equal, equalp are not enough; nothing should restrict itself to these comparisons. Generally all functions like +, -, equal etc. should be overridable for user's custom types with the efficient compile-time dispatched generic function mechanism. This would allow (explicit) laziness! Possibly kill the many bizarrely named or strangely parameterised and hardly used functions like `get'. (3) Stuff all implementations provide but is not standard Unsafe machine pointers Weak pointers Details from room GC Stack frame inspection etc. (4) Libraries that basically already exist but would be useful as part of the standard cl-ppcre, local-time, osicat, cffi, etc.

5 7

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

04 Sep '09

2009/9/1 Drew Crampsie <drewc(a)tech.coop> > 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! :) > Well, maybe I didn't expressed myself clearly. And I didn't quite get your point. If you go down that road, we could say that we don't need to standardize FFI or threads as well ("just use CFFI or bordaux-threads" - usocket is just as much of a portability layer as CFFI or bordeaux-threads is). In the part of "just create a small layer on top of them", I meant internally in each implementation. Each implementation will take the functions to manipulate sockets that it already has and create the standard functions on top of them or make small modifications appropriately to make those functions conform with the standard. This is what I believe that will be done by implementations to conform FFI, thread and any other standard we create here, isn't it? > > 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. > My point is that every implementation already support sockets, it should be much better if there was a standard interface so they could implement socket interface uniformly across implementations. > > 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. > I believe it would also be possible to implement multiple threading that way (using FFI, if it support callbacks (as CFFI does)). But I'm not going further on this topic. > > 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). Using IOlib has its drawbacks. It is a big library, one more dependency and it will only add functionality that is already present in all Lisp implementations. It also uses grays streams, which are not optimized streams (so implementation specific's sockets should be faster for good implementations). And it uses FFI, which is a barrier when you need to save and load lisp images. > > > 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. Fair enough. > [snipped] > > 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. > I still can't really see why standardizing sockets is so different from other topics that were included. I agree with you when you say our time will be better spent in other subjects for now, but I really think we should discuss this at some point. Lack of standard sockets is one of the topics that are most oftenly mentioned when the subject is "what are CL's negative points". Well, I guess I am the one playing the devil's advocate now :) > > > [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 > > By the way, a few more topics that can be discussed: * Features (as in trivial-features - e.g. when should x86-64 or x86 or darwin features be provided) * (Per-package ?) Readtables (I believe we *really* should discuss about readtables, it would avoid many of the hacks that are needed for using read macros - clsql is the canonical example) * Declarations and other optimizations - For instance, ECL has a declaration to freeze some generic function to avoid redefinition or including new methods, which is used for optimization. Freezing functions and types may be useful as well. Something like a standard sb-ext:defglobal<http://www.sbcl.org/manual/Global-and-Always_002dBound-variables.html#Globa…>, including sb-ext:global and sb-ext:always-bound proclamations, are welcome. I don't know if these are good ideas, but it would be very simple and easy to both include and implement (since actually using the declarations is optional, and defglobal can be implemented as an usual defvar).

6 6

[cltl3-devel] Types
by Levente Mészáros 04 Sep '09

04 Sep '09

Hi, Some issues about the type system that comes to my mind (some of them might be less important than the others): - no reliable way to figure out whether something is a type specifier or not - no way to portably expand a type specifier by using its definition - practically there is no reflection on types - no easy way to specify a parametric type of strings with less than N characters (this is just an example of the issue: (deftype length-limited-string (limit) ...) due to the limits of satisfies - no portable way to get the inferred type of a function, a variable, etc. Cheers, levy -- There's no perfectoin

2 1

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

02 Sep '09

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. > > A few more topics that could be discussed: > > (j) Interface to Environments, which is needed in a macro walker (e.g. > cl-walker accesses lexical environments using implementation specific > functions). I'm interested in this as well... but macroexpand-dammit shows one doesn't need environments to do a portable walker. However, most lisps have CLtL2 environments at least, so i'll add this to the list. > (k)Custom Hash Functions and Hashtable Test (SBCL's extensions). This is covered by a CDR, and so is on the list already. > (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 :) drewc > > 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 > >

5 6

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