Here are a few items on my post-ANSI wishlist. Please forgive me if I'm not following proper CLtL3 wishlist protocol.
* Get REQUIRE right. IIRC, CLtL2 had *MODULE-PROVIDER-HOOKS*. This is good. There should be a standard way for defsystems to coexist.
* If versioning semantics are added to REQUIRE, I suggest something like - (require system &optional version), NIL matches any version - require signals an error if the requested version doesn't match a currently loaded version - versions have three numbers (a la libtool) - "major" number represents external API changes (e.g. new functions) - "minor" number represents internal changes (e.g. bugfixes) - "range" counts minor numbers that are binary compatible - Example: 5.7.2 - API 5, release 7, backwared compatible with 5.6.x and 5.5.x - projects compiled against 1.x.y-4.x.y will need to be recompiled and may also need code changes - projects compiled against 5.0.x-5.4.x will require a recompile but no code changes
* Standardize read macros that dispatch on a symbol. The current read-macro namespace is too crowded. Here are a couple syntax variants. The first lets the dispach function read everything; it takes the current standard read-macro arguments. The second uses a normal read to get the default arguments; it takes the read-macro arguments as special variables. - #?(read-if (= 1 2) :true :false) dispatch to #'read-if which reads "(= 1 2)", skips :true, and reads :false - #!(read-if nil)(:true :false) dispatch to (read-if nil), which skips :true and reads :false
* 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.
* Provide a standard code walker.
* Define a standard mapping between pathnames and files on the major OSs.
* Split CL into smaller packages like CL.ALIST, CL.PLIST, etc. Use symbol macros for symbols in CL.
* Provide a standard way for macros to query type-inferencing info, declarations, etc.
* 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
* Define CL's memory model in a multithreaded environment, a la JSR133. http://jcp.org/en/jsr/detail?id=133
Later, Daniel
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."
- Define a standard mapping between pathnames and files on the major OSs.
That's a big and important one indeed.
- 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:-)
- Provide a standard way for macros to query type-inferencing info, declarations, etc.
That would be Very Nice Indeed.
- 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?
Robert Uhl scripsit:
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.
However, downcasing plays better with Unicode than upcasing does, because there are many Unicode lower-case letters without upper-case equivalents, whereas there are no upper-case letters without lower-case equivalents. The Unicode stability policies guarantee that:
a string properly downcased in the current version of Unicode will remain so in all later versions;
if two characters form (or do not form) an upper/lowercase pair in the current version, they will form (or not form) one in all later versions.
-- John Cowan cowan@ccil.org "You need a change: try Canada" "You need a change: try China" --fortune cookies opened by a couple that I know
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
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.
-
Daniel Herring -
John Cowan -
Marco Antoniotti -
Robert Uhl