[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Speed of FUNCTION-PARAMETER-RANGE
- To: NGALL@G.BBN.COM
- Subject: Speed of FUNCTION-PARAMETER-RANGE
- From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Date: Thu, 3 Jul 86 03:12 EDT
- Cc: COMMON-LISP@SU-AI.ARPA
- In-reply-to: <[G.BBN.COM] 3-Jul-86 02:29:33.NGALL>
- References: <860702222311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 3 Jul 1986 02:29-EDT
Out of curiosity, why do you feel the need for a 'fast' version of
function-parameters? I got the feeling that most people thought that
it would not be used in time-critical code.
Most people thought that. I guess they were wrong. I have counterexamples.
If it is not going to be used in tight-loops, do we really need the
separate 'speed' functionality?
Yes. In embedded languages which use their own interpreters rather than
calling EVAL (eg, Macsyma, Scheme, ...), you may wish to enforce
number-of-args checking even if the implementation you are running is
Also, Macsyma has a situation where it's been asked to defer the
application of certain kinds of functions and just return what we call a
noun form. ie, (SIN X) where X is 3 might yield the symbolic expression
(SIN 3) rather a numeric approximation such as 0.14112002 . There's a
command that later asks Macsyma to go through and evaluate nounds.
Even though the function for a noun doesn't get applied at the time the
rest of an expression is being evaluated, it may be desirable at the
interpreter to go ahead and do a preliminary check for correct number
Both of these situations want to be very fast because they occur in MEVAL,
the Macsyma analog of EVAL, and can consequently happen quite often.
If you or anyone else has further queries, I'll gladly answer them, but
I suggest we carry them on in private mail. I think I've made my point
and my guess is that most readers are tired of this line of discussion