This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
From: tb@xxxxxxxxxx (Thomas Bushnell, BSG) Date: 05 Jan 2004 18:31:01 -0800 Richard Kelsey <kelsey@xxxxxxx> writes: > Look, the problem here is easy: > > 1) Your SRFI demonstrably loses on certain kinds of implementations; > 2) There is a minor change which will make it not lose. > > Why on earth not prefer number (2)???? > > Clue me in. What is the minor change? A lot of different > suggestions have been made. It's like you blow up a building and then complain that there's too much dust to accurately say anything has been damaged at all. "Show me the damaged part of the building." I can't, the building is gone. You said 'easy' and 'a minor change'. Now you say that you can't tell me what that change is? There have been several different changes suggested. Tom Lord suggested that you might mean using the JNI or the Pika approach. I don't regard switching to either of them as a minor change and was trying to find out if you did regard it as such, or if you had something else in mind. The building may be gone, but the SRFI text is intact, the mailing archive is intact, nothing has been lost except perhaps your patience. Try counting to ten and then tell me what you have in mind. Or find the URL to some earlier posting that says it. I am not completely obtuse, but there have been so many mistatements and errors, and so much confusion and exaggeration in this discussion that I really don't know what you have in mind. SCHEME_FALSE should not be assumed to be a C constant; The SRFI doesn't do this. All it says is that evaluating SCHEME_FALSE won't cause a GC. Even if it could cause a GC, it is easy for the user to arrange things so that it won't. If it's easy for the user, why shouldn't the implementation do it and save the user the trouble? you cannot assume that eq? and == are the same; The SRFI doesn't do this. It doesn't even mention ==. you cannot assume that you have complete control over when other threads run. The SRFI doesn't do this. It does make some assumptions, yes, but far from complete control. See the above comment about confusion and exaggeration. -Richard Kelsey