[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: FUNCTION-COERCE-TIME (Version 2)
- To: masinter.pa@Xerox.com
- Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 2)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 7 Nov 88 20:12 EST
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <881107-150710-1136@Xerox>
Not only do I wish FUNCTION-TYPE would get changed back, but I think it is
appropriate for us to word things in such a way that they infringe on some
implementation-specific extensions.
To take an example from another domain, the Scheme community was discussing
defining EQ on symbols as simply comparing the print names (because Scheme
doesn't have gensyms). I tried to talk them into mentioning that this was
only incidental and that if gensyms were introduced that the (formal semantics)
location of the symbol should be used, not its print name. I met with
opposition from people who said that we (Scheme) shouldn't be saying how
people extend things. But I continue to believe it would be a disaster if
someone extended Scheme to make EQ do anything other than pointer comparison
for non-interned symbols.
Getting back to this point, then, I think it's a good idea not only to separate
the issue of FUNCTION-TYPE from this issue, but also it's good to adopt wording
that says what we mean it to say in the case where we can reasonably anticipate
extensions.
By the way, I'm thinking of circulating a revision of this proposal which
might lean more toward explicitly vague on some of these issues. At the same
time, I'd like to encourage the use of the DEBUG and/or SPEED quality to help
compilers lean toward LAZY in the slow/easy-to-debug case and AMBITIOUS in the
fast/hard-to-debug case. There are some details to be worked out, though...
Does anyone have any thoughts on that.