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

Re: [spr7115] (declaim (ignore...))



   From: george@hsvaic.boeing.com (George Williams)
   Date: Fri, 4 Dec 1992 07:16:25 -0600
   To: Allegro-CL@ucbvax.berkeley.edu
   Subject: (declaim (ignore ignore))

   This was posted a while back on the MCL mailing list, and I never saw
   any responses.  Is there a reason that this doesn't work in ACL 4.1?

   George Williams            BCS Huntsville Advanced Computing Group
   Boeing Computer Services   Internet: george@hsvaic.boeing.com
   POBox 240002, M/S JY-58    UUCP: ...!uw-beaver!bcsaic!hsvaic!george
   Huntsville AL 35824-6402   Phone: 205+464-4968 FAX: 205+464-4930

   --- Forwarded mail from hall@allegra.att.com (Bob Hall)

   Date: Tue, 1 Dec 92 09:34:33 EST
   From: hall@allegra.att.com (Bob Hall)
   To: info-mcl@cambridge.apple.com
   Subject: (declaim (ignore ignore))

   The toplevel form
     (DECLAIM (IGNORE IGNORE))
   works nicely in MCL to allow me to write, e.g.
     (DEFUN FOO (IGNORE) 4)
   and avoid a compiler warning.  Also nicely, it issues a warning
   if I DO use IGNORE when I declaimed it to be ignored.

   What I'm having trouble with is whether this is defined in
   "the" language (CLtL2? ANSI?) or is it an
   extension?  It doesn't work in, for example, Allegro CL v4.1.
   The DECLAIM above appears to have no effect, though it doesn't warn/error.
   My recollection is that Symbolics CL just implicitly does the DECLAIM;
   that is, if you name a local variable IGNORE, then the compiler
   knows not to issue "unused" warnings.  (I don't remember if it warns
   if you DO use such a var).

   -- Bob

   --- End of forwarded message from hall@allegra.att.com (Bob Hall)

The reason you didn't see a reply is that Bob Hall happened to send
inquiries in parallel to both allegro-cl and bugs@franz.com.  I sent
Bob a partial answer to the latter after the question was entered into
our tracking system as spr7115.

The issue isn't as simple as one might expect.  I've reproduced my
partial analysis below, since the issue is apparently of general
interest, and added you and allegro-cl to the cc list for the spr so
that when there is a more definitive response you'll receive that too.

====================

Date: Tue, 1 Dec 92 13:19:22 PST
From: smh (Steve Haflich)
To: hall@allegra.att.com
Subject: Re: [spr7115] (declaim (ignore...))

[This matter has been assigned the tracking identifier "spr7115".
Please refer to it in any followup communication.  Also, be sure
to cc bugs@franz.com so that if I am unavailable someone else will
be able to respond.]

   From: hall@allegra.att.com (Bob Hall)
   Subject: (declaim (ignore...))

   It seems to me the following ought to silence the compiler warning:

   (DECLAIM (IGNORE IGNORE)) ;; at top-level

   (DEFUN FOO (IGNORE)
     4)

   but it doesn't in Allegro v4.1 final on a sparc II.
   (It works in other CLs, such as Macintosh CL.  In Symbolics, the compiler
   just automagically knows that anybody who names a variable IGNORE doesn't
   want to be warned if it is ignored.)

   Thanks,

   -- Bob

   p.s.  Similarly, (PROCLAIM '(IGNORE IGNORE)) also fails to work in Allegro.

I first thought the question was rather straightforward, but as I
started checking the dpANS the waters rapidly deepened.  So the
following is a partial answer, pending more research.

First, the Lisp Machine convention that variables named IGNORE should
automatically be treated as having the IGNORE declaration is
definitely not compatible with the dpANS.  X3J13 considered this
convention directly and decided to reject it -- I don't remember
exactly, but probably on the grounds that the language didn't need one
more special-case irregularity that was just a trivial variation of
more-general syntax (i.e., the normal IGNORE declaration).  It isn't
particularly bothersome that Symbolics might have opted to preserve
it, considering the large body of existing Symbolics code, and since
the nonconformance only affects the issuance or non-issuance of
compile-time warnings.  But Franz consciously decided to stick with
strict portable behavior here.  Users porting code can easily fix
instances of this nonstandard usage the first time they compile.

The issue of (DECLAIM (IGNORE IGNORE)) on the other hand turns out to
be really convuluted.  There are a couple tangled subissues.

First the trivial reason why this isn't legal: There are a number of
restrictions on portable programs spelled out on CLtL2 pp259-261.  The
basic idea is that you can't redefine any operator (i.e. function) or
variable definitions on symbols in the COMMON-LISP package.  The
obvious reason is that portable user code can't tell what it might
break by redefining part of the underlying implementation.  But
furthermore, the restrictions are carefully designed to prevent even
making a global variable or operator definition on a symbol even if
that symbol does not have such a definition.  The reason (unstated) is
that while _one_ portable application might get away with doing this,
this creates a serious danger of name collision if _another_ allegedly
portable application does exactly the same thing.  These restrictions
therefore are tacit recognition that portable code shouldn't assume
that it the only citizen in the lisp world.  It has to be a good
neighbor to other applications that might live in the same world --
and which might not be loaded until some time in the distant future.

Now, the restrictions prevent doing things like making global type
proclamations on symbols.  The issue of making global IGNORE
proclamations isn't addressed.  (This assumes for the present that
such a proclamation would have global effect -- this is the trickier
point I'll address later.)  I believe this is just an oversight,
because if an application happens to establish such a proclamation it
could break an implementation that happened to use the same symbol to
name a regular lexical variable, and which happened to use the
compiler at run time.

I consider the above as a compelling `language lawyer' argument
against trying to establish an IGNORE proclamation on the symbol
COMMON-LISP:IGNORE.  But this argument misses the main point, and much
more interesting question, whether the language's scoping semantics
causes such a proclamation to be effective or ineffective.  To avoid
language lawyers, we can recast the question as

	(declaim (ignore unused))

	(defun firstarg (x unused) x)

where the symbol UNUSED is, say, in the USER package.  The above
proclamation is definitely legal according to the dpANS, but there is
a question whether it has the intended effect.  Under an alternative
interpretation, the proclamation would cause a warning if any code
ever declared the variable SPECIAL, but would not be pervasive to
lexical bindings such as are established by lexical variables in
lambda lists.

As you may be aware, X3J13 made some changes in the scoping semantics
-- the `pervasiveness' -- of declarations, and these are reported in
CLtL2.  However, I couldn't remember if there were some later changes
after CLtL2, so I started checking the dpANS.  The dpANS has recast
scoping semantics in somewhat different terms -- i.e., the term
"pervasive" is no longer even used.  I started slogging through this
swamp, but ran out of time.  It is something that I definitely want to
resolve, because it is either a bug or ambiguity in the dpANS, or if
not, it might (or might not) be a bug in Allegro.

It will probably take a few days before I have sufficient time to slog
the rest of the way through the dpANS, but I wanted to let you have
this partial analysis in the meantime.

====================

Date: Tue, 1 Dec 92 16:41:41 EST
From: hall@allegra.att.com (Bob Hall)
To: smh@Franz.COM
Cc: bugs@Franz.COM
Subject: [spr7115] (declaim (ignore...))

Thanks for the partial analysis.  I take your point about the declamation
applying to symbols in the common-lisp package.  I am more interested in
the larger issue, though, since I can easily use "UNUSED" or "IGNOR" ,etc
if they are legal and portable to declaim as ignored.  I'll be interested
to hear any further determination you make.

====================