Coming up with a backward compatible case folding behavior is not that easy. This is an excerpt of my half-baked proposal for case folding during the discussions that ensued on CLL after Franz introduced "Modern" mode, thus breaking backward compatibility.
Of course, one wonders what they were smoking in the Boston area when the California guys (who, it is understood, were at least dining with Sonoma Valley wine) proposed straightforward case-sensitivity for ANSI CL.
Cheers -- Marco
On Sep 8, 2009, at 02:44 , Daniel Herring wrote:
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
cltl3-devel mailing list cltl3-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 Viale Sarca 336 I-20126 Milan (MI) ITALY
Please note that I am not checking my Spam-box anymore.