[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: FUNCTION-TYPE
- To: cl-cleanup@Sail.stanford.edu
- Subject: Re: Issue: FUNCTION-TYPE
- From: Masinter.pa@Xerox.COM
- Date: 22 Sep 87 14:11 PDT
- Cc: willc%tekchips.tek.com@RELAY.CS.NET
I've thought about FUNCTION-TYPE on and off over the summer, as one of
the more important issues for us to revisit. I've changed my mind; I am
now in favor of STRICT-REDEFINITION as long as the proposal that
specifies that it "is an error" to give symbols to functions that expect
functions. ) as long as the restriction is "is an error" rather than
"signals an error".
I think that the proposal has technical (linking, analysis) and
aesthetic (cleaner language semantic) advantages, and that backward
compatibility is well-served by noting that many implementations will
continue to support automatic coercion.
I think we owe X3J13 a new draft of the proposal with fewer (rather than
more) alternatives expressed.
All of the alternatives expressed so far have some flaws. I'm willing to
work on the STRICT-REDEFINITION proposal to correct its problems (e.g.,
deal with *MACROEXPAND-HOOK*, add COERCE to type FUNCTION).
Are there any volunteers to work on any of the other proposals?