[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PACKAGE-CLUTTER (Version 2)
- To: Scott.Fahlman@B.GP.CS.CMU.EDU
- Subject: Re: Issue: PACKAGE-CLUTTER (Version 2)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 28 Sep 88 12:12 EDT
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: The message of 27 Sep 88 22:23 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Date: Tue, 27 Sep 88 22:23:54 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Date: Tue, 27 Sep 88 13:04:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Symbols on the LISP package may have function or macro
definitions, variable definitions or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
Neither users nor implementors are permitted to add new kinds of
definitions for these symbols.
I don't know what "variable definitions" means.
Does this mean that I, as a user, am not allowed to use symbols such as
LIST, MEMBER, or SYMBOL as a lexical variable in my own protable code? If
so, I am very strongly opposed to this. The conversion cost would be very
high, and I don't see any safety issue that would force us to restrict the
user in this way. If that is not the intended meaning, perhaps some
clearer wording is needed.
I'd go along with the other cases.
I wasn't really thinking about this issue, but I'd be happy if you
couldn't have global definitions of LIST, MEMBER, etc. or SPECIAL
bindings of them. But it's ok with me if you have lexical bindings of them.
Would that satisfy you. Does that seem to inconsistent to anyone?