[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>
To:Gall@MIT-MULTICS.ARPA
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>
To:common-lisp@SU-AI.ARPA
CC:Gall@MIT-MULTICS.ARPA
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
type-inference.
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
strings.
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)
T
* (symbol-package 'xyzzy)
{printed rep. of p1}
* (unintern 'xyzzy p1)
T
* (symbol-package 'xyzzy)
NIL
* (intern "XYZZY")
XYZZY
:INTERNAL
* (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
UNINTERN:
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
error.
In the above case, shouldn't UNINTERN just automatically
shadow-import the other symbol?
------------------------------------------------------------