On Jul 10, 2012, at 4:29 AM, Marijn wrote: > On 09-07-12 03:57, Paul Schlie wrote: >> Aaron W. Hsu Scripsit: >>> If performance is important, then use one of the already useful >>> and good Scheme implementations out there that produce fast code. >>> If you do not care about speed, feel free to use a naive >>> implementation, but do not expect it to be fast. >> >> Sorry, I don't understand; as the issue is about what r7rs should >> be, isn't it. > > I think the conversation (up to the point you quoted) went something > like this: > > Will Clinger: The R5RS semantics lead to bad code and performance > hacks. The R6RS semantics are more efficient in the general case. > (Thus R7RS should specify the R6RS semantics.) > > John Cowan: Performance hacks are important on slower implementations. > (Thus R7RS should specify the R5RS semantics.) > > Aaron W. Hsu: If you want speed, use a fast implementation! (Thus R7RS > should specify the R6RS semantics.) > > Hope that clarifies,
It does thank you; however it's not clear to me that something being fast/efficient because it's unspecified, is actually a good thing, or arguably truly fast or efficient. As then its use becomes non-portable, being it would seem contrary to at least an important objective of any standard. As within r6rs, some things seem questionable to me (but am confident that others more experienced and/or knowledgeable have given them due consideration): (let ((p (lambda (x) x))) (eqv? p p)) ⇒ unspecified (eqv? +nan.0 +nan.0) ⇒ unspecified _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
