[cltl3-devel] Case wars. Re: wishlist items

[Marco Antoniotti]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: case-war.zip
Type: application/zip
Size: 7037 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cltl3-devel/attachments/20090908/0aa0510f/attachment.zip>
-------------- next part --------------



Cheers
--
Marco



On Sep 8, 2009, at 02:44 , Daniel Herring wrote:

> 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
>
> _______________________________________________
> cltl3-devel mailing list
> cltl3-devel at 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.