Am 06.09.2009 um 09:35 schrieb John Fremlin:
It's awesome that the standard is getting revisited.
CLtL3 will only be a specification, not a standard. This is a big difference. Between CLtL2 and ANSI CL are significant differences and creating a standard like ANSI CL was a complex and costly task. We hope that the result of CLtL3 will be a specification that gets accepted as solid progress for Common Lisp as a programming language - not Common Lisp as a standard. I think time will show if there will be benefits if the standard itself will get revised.
The fact that there exists an established standard (ANSI CL) will have a stake on what we can do with CLtL3. It doesn't make any sense to me, to break ANSI CL support; a future CLtL3 capable Common Lisp should also work with programs written for ANSI CL.
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 others already outlined extending the type system could probably the most efficient way to drive CLtL3 against some wall. It's not impossible to implement your own type systems within Common Lisp without touching the CL type system at all. I think I remember reading Thomas Burdick talk about this on c.l.l before; maybe it was someone else. On the other side: I would be the last who would say NO! if someone can show how to extend the CL type system in a way that doesn't break ANSI CL code, is sound and (most important) is useful. I just think that this is maybe one of those parts we will not tackle with CLtL3.
As Levente also brought up: also access to type inference, etc. This would allow:
Efficient generic functions dispatched to inline expansions at compile time.
Generic functions do not dispatch on types, but on classes (and on EQL values). There exists some classes which correspond to types like numbers, strings a.s.o. This means you can already do something like:
(class-direct-subclasses (find-class 'number)) => (#<BUILT-IN-CLASS REAL 20945223> #<BUILT-IN-CLASS COMPLEX 20944833>)
The consequence is, that you cannot dispatch on all types expressible in CL. Allowing dispatch on arbitrary types is probably not easy and perhaps not very efficient. Though: Extensions to the dispatch system are a very interesting topic for CLtL3. AFAIK Pascal Costanza is working on some ideas to realize predicate dispatch within CLOS.
Value semantics.
Value semantics? I would like to here some more about why you think this is needed for CL and how it should work.
More help for code walkers and transformers (what does a declare form refer to?, etc.)
defining access to environments - I would like to see something like that too.
Limited(?) serialisation of closures.
Would be somewhat cool. More important to me would be compiling and loading code from a stream.
Ability to locally alias a symbol and package
Package-local aliases, nicknames for packages that are only valid within the package in which they are defined are quite possible. Perhaps ideas from Tim Bradshaws conduits package should be taken into account.
I fear locally aliasing a symbol is more difficult. You cannot mean creating a new symbol with the same name shadowing the first, because thats already how the package system works. So I think you actually mean accessing the _same_ symbol using a different name within a particular package. SYMBOL-NAME currently is a property of a symbol which is independent from the concept of a package. Following your idea SYMBOL-NAME would give different names depending on the value of *package* in the current dynamic extent. IMPORT is just defined on symbols and does not associate names with which the imported symbols are imported (because IMPORT gets them using the global symbol property SYMBOL-NAME); so one would need another function (e. g. called IMPORT-ALIASED) to associate a symbol with a particular name in the chosen package. A problem is though, that in ANSI CL there is this constraint were the symbol-name of a symbol is always the same - regardless of the current package - this could lead to problems with ANSI CL programms.
(2) Brokenness in the current Lisp standard
Different facilities should be separated and put into different packages.
More: New facilities defined in CLtL3 should be clearly modularised and - of course - get their own packages were applicable. You should recognize a CLtL3 using program easily by its usage of CLtL3 packages. There could be a common prefix like "CLTL3." for all those packages. Perhaps it would be interesting to expose existing ANSI CL symbols in different packages, but they will all have to be available in "CL".
Pathnames are overly complicated and do not handle symlinks well.
Windows XP doesn't handle symlinks well ;-) - The situation in common lisp is somewhat similar to that of java 2-3 years ago. They solved it in JSR 203. CL Pathnames are actually better than their fame. Im not sure what the best idea would be - more clearly define how pathnames should behave or just orthogonally implement URIs and make all functions who accept pathname designators let accept uris too (URIs as pathname designators). Either one would restrict those to file-URIs or one could establish a protocol to implement support for other schemes.
Extensible sequences, gray streams, etc.
Of course!
Hash-tables should be generalised like extensible sequences allow user implementation of other datastructures.
yes
eq, eql, equal, equalp are not enough; nothing should restrict itself to these comparisons.
http://www.nhplace.com/kent/PS/EQUAL.html
Generally all functions like +, -, equal etc. should be overridable for user's custom types with the efficient compile-time dispatched generic function mechanism.
This is already possible to some extend using symbol shadowing. I would not want to allow "operator overloading" like in C++ (shudder)
This would allow (explicit) laziness!
Possibly kill the many bizarrely named or strangely parameterised and hardly used functions like `get'.
"Kill" gets to far - this would break ANSI CL compatibility. We could deprecate their use and don't import them in the CLtL3 package(s) - so one could use CL:GET if one wants to.
(3) Stuff all implementations provide but is not standard
Unsafe machine pointers
Weak pointers
Details from room
GC
Stack frame inspection
Usefulness is king.
etc.
(4) Libraries that basically already exist but would be useful as part of the standard
cl-ppcre, local-time, osicat, cffi, etc.
Thats actually not a good idea (as discussed on the list before).
ciao, Jochen