Re: #T, self-evaluation, and NULL-LIST =? FALSE.

[<jphilbin%YALE-RING@YALE.ARPA>]

        In T, #T and #F are external syntax for true and false *objects*, not
        *expressions*.  #T and #F are not themselves supposed to be evaluable
        expressions.  Evaluable expressions which give true and false values are
        T and NIL, or, if you prefer, (TRUE) and (FALSE).
    
    However, note the following behavior:
    
       > (eq? (true) '#T)
       ()
    
    What then is the purpose of #T (or equivalently the
    *TRUE-OBJECT*)?  I realize the difference between #T and (TRUE),
    but I guess I was trying to say that I didn't see the need for
    #T, given that we have (TRUE) (or T, if you prefer).  It just
    seemed like unnecessary syntax (shudder!) to me.
    
The point is #T cannot be shadowed.  Since TRUE is just an identifier
it is not guaranteed to evaluate to the same thing in all environments.
The manaul says that (TRUE) returns some true object not the cononical
true object.

        In the long run I think the right thing to do is to somehow
        make the way that boolean and other objects evaluate
        (macroexpand) be a property of the syntax table...
    
    Again, why do we need syntax for booleans when we have T, NIL,
    (TRUE) and (FALSE)?
        
No. T, NIL, TRUE, and FALSE are identifiers bound in the standard
environment, and thus they can be shadowed.  #T and #F are read
syntax and are guaranteed to read as the canonical true and false
objects in any environment using the standard read table.

        ... (it's bad enough that numbers self-evaluate; where does
        one draw the line?)...
    
    I disagree.  The value of 34 is 34, not ERROR.
    
No again.  Your confusing the identifier represented by the character
sequence "34" and the number 34.  Maybe Jonathan can expand on this.

        ... (It would have helped if we had distinguished #F from
        () back in 1981 when we had a chance.)
        
    We all use the fact that the null list and the false object
    are the same while programming.  ...  The sugar helps in avoiding
    code clutter which would otherwise result from type checking
    all over the place.

You shouldn't be.  The null list and the false object are not
semantically the same and for example the compiler could detect
certain errors that it now can't if this difference were supported
in the language.  I don't see how making #F different from () causes
code clutter, could you explain?

    - Jim