[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Follow-up and New Questions

    From: Robert Elton Maas <REM@IMSSS.SU.EDU>
    Subject:Compiler warning msgs

    > !section  5.3.2(7)  Nick Gall 85-03-19
    > !version  Digital Press 1984
    > !topic    Lexical variable with the same name as a named constant
    > ... (illegal, can't do it)
    > If this is the case, when would the compiler ever have the
    > opportunity to
    >           ...issue warnings about bindings of the lexical variable of
    >     the same name [as a name declared by DEFCONSTANT to be
    >     constant].

    My guess is what is meant by "warning" is "nonfatal diagnostic
    message", i.e. the construction is illegal and the compiler can't
    possibly compile it into correct code, but the error doesn't crash the
    compiler, the compiler merely issues a diagnostic (warning) and
    proceeds to try to recover and compile the rest of the file.

I think you misunderstood my question.  Take this code for example:

          (defconstant const ...)

          (defun foo ()
            (let ((const 1))

One might think that the LET is binding a lexical variable named CONST; it is
not.  LET is binding a special var. named CONST.  This is due to the fact that
defconstant does an implicit proclaim.  This proclaim pervasively affects all
bindings of the proclaimed var.  This means that once a variable name appears
in a defconstant, there is no context in which the interpreter or compiler
would consider that name to be the name of a lexical variable.  So... there is
no way the compiler could ever warn the user that they are using a lexical
variable with the same name as a constant.  To put it briefly, I bet you can't
show me a piece of Common Lisp code that would cause such a warning.
    From: Robert Elton Maas <REM@IMSSS.SU.EDU>
    Subject: What should CLOSE return? Closed-channel-object, or truefilename.

    > !section  21.3(7)   Nick Gall 85-03-19
    > !version  Digital Press 1984
    > !topic    What does CLOSE Return?
    > I think it should return the STREAM it was given to close.  This
    > would make it symmetric with OPEN: OPEN returns an open stream,
    > CLOSE returns a closed stream.

    That's not symmetric, that's coercive. OPEN and CLOSE are like
    matching parenthesis, one does it and the other undos it except for
    a residual side-effect. OPEN takes a name and returns an I/O channel
    (at the LISP level, an object that can be name an active stream of
    data). CLOSE takes an I/O channel and should return a name to be
    symmetric with OPEN. This would be an opportune time to solve race
    conditions where several users are making different versions of the
    same file at the same time by the trick of writing a temporary file
    and then renaming it during the CLOSE. At CLOSE the version number is
    determined, and at that moment before somebody can create a later
    version the lisp CLOSE function obtains the true filename of the
    particular version we created.

You're right `symmetric' is the wrong adj.  But I still think CLOSE should
return the (closed) stream.  It can't (always) return the truename of the file
associated with the stream, since not all streams are associated with files.

How can one rename a file `during' a CLOSE?  CLOSE should not return until the
stream is really closed (and the file associated with the stream is quiesent).

To obtain the truename of a just closed file, one could write

          (truename (close x))          ; where x is bound to a file stream

since truename will take a stream as an argument.  (Unfortunately,
the CLRM (23.1.2(5)) is only explicit about what truename does
with an `open' stream.)
    From:  Rob MacLachlan <RAM at CMU-CS-C>
    Subject:  Default attributes of copy due to SUBSEQ
    To:  REM at MIT-MC
    cc:  common-lisp at SU-AI, Gall at MIT-MULTICS

        The semantics that I favor (and those implemented by Spice Lisp)
    are that every Common Lisp function which returns an array returns a
    simple array unless the function is make-array or one of the arguments
    is eq to the result.  This has the advantage of being a simple
    specification, and also allows the compiler to do more interesting

Your semantics are correct:

          Whenever a sequence function must construct and return a
        new vector, it always returns a SIMPLE vector (see
        section 2.5).  Similarly, any strings will be simple
                                        CLRM 14.0(last paragraph)

Sorry I didn't see this sooner...
!section  11.7      Nick Gall 85-03-20
!version  Digital Press 1984
!topic    INTERN's effect on an accessible symbol's owner.

          As a verb, to `intern' a symbol in a package means to
        cause the symbol to be interned (sic) in the package if
        it was not already; this function is performed by the
        function INTERN.  If the symbol was previously unowned,
        then the package it is being interned in becomes its
        owner (home package)...
                                        CLRM Section 11.0 (pg. 172)

I interpret this passage in the following way:

;; Current package is USER

* (setf p1 (make-package 'p1 :use '()))
{printed rep. of p1}

* (import 'p1::xyzzy)

* (symbol-package 'xyzzy)
{printed rep. of p1}

* (unintern 'xyzzy p1)

* (symbol-package 'xyzzy)

* (intern "XYZZY")

* (symbol-package 'xyzzy)
{printed rep. of user}

In other words, INTERN ensures that the symbol that it returns
as its first value has a home package.

Is this interpretation correct?

!section  11.7      Nick Gall 85-03-20
!version  Digital Press 1984
!topic    UNINTERNing a shadowing-symbol

When uninterning a shadowing symbol (call it foo), UNINTERN
collects all inherited symbols with the same print-name
as foo, including foo (assuming foo was inherited).  If the name
conflict is only between foo and one other symbol, what sense
does it make to signal a name conflict error and give the user a
choice between shadow-importing foo and the other symbol.  If the
user chooses foo, it is no different from aborting from the

In the above case, shouldn't UNINTERN just automatically
shadow-import the other symbol?