[cltl3-devel] wishlist items

[Daniel Herring]

On Mon, 7 Sep 2009, Robert Uhl wrote:

> Daniel Herring <dherring at tentpost.com> writes:
>>
>> * 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.
>
> I think that setting *PRINT-CASE* to :DOWNCASE goes a long way to
> soothing the headaches of a language which defaults to
> upcasing...internally everything is upcased but it displays
> attractively.
>
> Once that's done a lot of the impetus for playing with case-folding goes
> away.  The only nuisance is in using strings to refer to symbols, where
> one must actually use "FOO" instead of "foo."

I disagree.  "He lost his mit at MIT."  "For all x in X..."  For many 
applications, case folding is fine.  For others, it is almost completely 
unworkable.  There should be a way for different conventions to peacefully 
coexist.  Test implementations indicate it is completely doable, the 
biggest question is one of acceptance by the existing CL community.


>> * Split CL into smaller packages like CL.ALIST, CL.PLIST, etc.  Use
>>    symbol macros for symbols in CL.
>
> What's your rationale there?  Seems like it'd eat up resources without
> any real benefit.  But I imagine I'm missing something important:-)

So a package can (:use CL.ALIST) to only get CL's symbols for manipulating 
alists, etc.  These packages would also provide convenient namespaces for 
renamed symbols like copy-alist -> alist:copy or pairlis -> 
alist:add-pairs.  But such renames may be outside the CLtL3 charter. 
Another possibile package would be CL.GENERIC for things like a + generic 
function.


>> * 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
>
> Is this the same as generalised sequences?

Yes modulo the details; they are closely related ideas.

- Daniel