[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gall: Bug Report]
Date: 28 March 1985 16:56 est
From: Daniel L. Weinreb <DLW at SCRC-STONY-BROOK>
Subject: [Gall: Bug Report]
Date: Wed, 27 Mar 85 20:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
were EVAL-WHEN permitted inside a function body (it is not; see p.66).
On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
Are we reading the same page 66? Mine says "It is not illegal to use
these forms at other than top level, but whether it is meaningful to do
so depends on context." To my ears, this is sort of like saying
that integers can be of any precision, but after they get larger
than the fixnum limit, their behavior depends on context.
Also, note the wording in the description of DEFUN on page 67: "Because
DEFUN forms normally appear at top level, this is normally the null
lexical environment." This wording strongly suggests that DEFUN might
sometimes not be at top level, and the environment is not necessarily
always null. After all, if DEFUN were only allowed at top-level, why
bother with the "normally" qualifiers? But you never find out anything
I'm not advocating either side right at the moment; my point is that the
manual is ambiguous (one might even say "coy") on this subject.
Hmm! I thought ALL integers were infinitely precise.
As to defuns at other that top level, on pg. 67 it says
Evaluating a defun form causes the symbol NAME to be a global
name for the function specified by the
lambda-expression...DEFINED IN THE LEXICAL ENVIRONMENT IN
WHICH THE defun WAS EXECUTED.
I take this to mean that the CLRM specifically allows and defines
the correct semantics for non-top-level use of DEFUN.
I think pg. 66 is what needs cleaning up (i.e., it should
enumerate the correct uses of `Top-Level' forms). "Depends on
context" is equivalent to "is undefined" in my book.