Re: case sensitivity of provide, require and module-provide-asdf

Chris Stacy <[email protected]> writes:

>     On May 26, 2016, at 1:48 PM, Pascal J. Bourguignon
>     <[email protected]> wrote:
>     
>     Raymond Toy <[email protected]> writes:
>         I think you meant upcasing. 'ABC and 'abc are both the same
>         symbol
>         whose name is "ABC".
>         
>
>     Wrong:
>     
>     cl-user> (EQ 'ABC 'abc)
>     NIL
>     cl-user> (MAPCAR 'SYMBOL-NAME '(ABC Abc abc))
>     ("ABC" "Abc" "abc”)
>     
>
> I think someone reading this might get confused about case in Common
> Lisp.
> Normally, (eq ‘abc ‘ABC) => T of course, since READ upcases symbols.
> Also (eq #’eq #’EQ) => T for example.
> But symbol names are case-sensitive, and Pascal’s confounding example
> above
> left out the part where he trickily altered the “readtable case” of
> the current reader,
> causing it ti preserve case. Notice that he typed uppercase EQ,
> because the
> symbol-name of EQ is (like all Common Lisp built-ins) actually
> uppercase.
>
> See: http://www.lispworks.com/documentation/lw51/CLHS/Body/23_aba.htm
>
> Don’t want to confuse any readers about the readers…

Yes, I left out the setting of the readtable-case. >:-}

    ; SLIME 2015-06-01
    cl-user> (setf (readtable-case *readtable*) :preserve)
    :PRESERVE
    cl-user> (EQ 'ABC 'abc)
    NIL
    cl-user> (MAPCAR 'SYMBOL-NAME '(ABC Abc abc))
    ("ABC" "Abc" "abc")
    cl-user> (SETF (READTABLE-CASE *READTABLE*) :UPCASE)
    :upcase
    cl-user> (eq 'ABC 'abc)
    t
    cl-user>


The important word in this thread was:


Sam Steingold <[email protected]> writes:

>> * Daniel Jour <[email protected]> [2016-05-15 21:40:41 +0200]:
>>
>> Given the ignorance of case prevalent in Common Lisp,
>
> the only places where this happens are:
> 1. reader is case-converting by default
                               ^^^^^^^^^^

"BY DEFAULT"

The initial value of global variables, and the initial configurations of
the objects they refer to, can be left undefined
(implementation-dependent), for example:

    Variable *PRINT-PRETTY*
    Initial Value:
    implementation-dependent.

or a default initial value can be specified by the standard:

    Variable *READTABLE*
    Initial Value:
    A readtable that conforms to the description of Common Lisp syntax
    in Section 2 (Syntax).


    2.1.1.3 The Initial Readtable

says that the initial *readtable* conforms to the standard syntax, which
is defined by the Standard Readtable, and:

   2.1.1.2 The Standard Readtable

says that:

     The readtable case of the standard readtable is :upcase.


(By the way, my reading of section 2.1.1.3 is that implementations
should not deviate from the standard readtable, eg. they should not
provide implementation specific reader macros in the initial readtable
(as ccl does, for example)).



Now, all those variables can (and most of them probably should) be set
in the rc file (~/.clisprc.lisp, etc) by the user.

The consequences are that:

1- as a user, you must know what you've put in the rc file, and
   therefore what is the current setting of those variables.  You could
   have:
 
         (SETF (READTABLE-CASE *READTABLE*) :PRESERVE)

   in your rc file, and use  uppercase letters (their real case) for all
   the CL symbols.


2- I would argue that library sources should NOT assume a readtable, and
   like they include a IN-PACKAGE form at the start of each source file,
   they should also include a form setting the *readtable*, such as:

        (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
          (SETF *READTABLE* (COPY-READTABLE NIL)))

   in each source file, or at the very least, there should be a way in
   ASDF (and other similar system definition systems), to specify the
   readtable to be used to load and read the sources of the library.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel