[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: COERCE-INCOMPLETE (Version 3)
- To: firstname.lastname@example.org
- Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 17 Mar 89 12:05 EST
- Cc: barmar@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM, email@example.com, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <8903171654.AA06800@defun.utah.edu>
[X3J13 removed as overkill for this level of discussion; CL-Cleanup added]
Date: Fri, 17 Mar 89 09:54:35 MST
From: firstname.lastname@example.org (Sandra J Loosemore)
... BarMar is right. I have a hardcopy of the FUNCTION-TYPE writeup that
was mailed on 4 Sep 88, with a note from Larry indicating that it's
the final version as passed at the June meeting. It includes
COERCE'ing of lambda expressions to functions as item 6b. ...
Yeah, it's the same in my copy. Sorry about that. I just stopped reading
too soon. Thanks for catching this.
I don't think this is a valid argument for not getting rid of COERCE,
since it is easy to coerce a lambda expression to a function using
(EVAL `(FUNCTION ,x)).
I mostly agree, but I admit that most other coercion operators don't force
you to cons unnecessary intermediate structure in order to do the coercion.
Having something like the original SCHEME's ENCLOSE operator wouldn't bother
me at all. Too bad we didn't pick the name DISCLOSE for what ended up being
FUNCTION-LAMBDA-EXPRESSION. I guess the right name for the ENCLOSE function
at this point is LAMBDA-EXPRESSION-FUNCTION.