On Mon, 7 Sep 2009, Robert Uhl wrote:
Daniel Herring dherring@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