[cltl3-devel] RFC: CLtL3 Charter

[Jochen Schmidt]

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


-- 
Jochen Schmidt
CRISPYLOGICS
Uhlandstr. 9, 90408 Nuremberg

Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83

mailto:(format nil "~(~36r@~36r.~36r~)" 870180 1680085828711918828  
16438) http://www.crispylogics.com