[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
- From: masinter.pa@Xerox.COM
- Date: 20 Sep 88 00:13 PDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of Sat, 12 Mar 88 20:02 EST
The last message I can find on this issue is your message of last March. I've
misplaced Mathis message with the last minutes meetings; while I did note most
of the issues that were passed and discussed.
This one I recall was held up pending the function-spec proposal. However, I'm
suprised we don't have a writeup past Version 3, given what I think were
reasonable comments from Kent.
Did I misplace some mail?
Date: Sat, 12 Mar 88 20:02 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
I support many ideas of this proposal, but I have two gripes which make me
have to oppose it:
* I can't deal with the idea of generalizing SYMBOL-FUNCTION. I would like
to see FDEFINITION introduced and SYMBOL-FUNCTION left alone.
* I'm also a little leary about TRACE being extended this way because
(TRACE (a list)) might later want to be interpreted as options rather
than as a function spec and I'd rather not have to risk heuristic resolution.
I would rather someone right now introduce a generalized syntax for TRACE
with syntactic space for trace options, such as
(TRACE (fn . options) (fn . options) (fn . options))
and then allow the generalized (non-symbol) fn to only occur within that
syntax so that no ambiguity results.