Re: no constants please
Richard Kelsey
(04 Jan 2004 18:11 UTC)
|
Re: no constants please
felix
(04 Jan 2004 19:25 UTC)
|
Re: no constants please
Richard Kelsey
(04 Jan 2004 20:08 UTC)
|
Re: no constants please
Tom Lord
(04 Jan 2004 21:13 UTC)
|
Re: no constants please
Tom Lord
(04 Jan 2004 21:43 UTC)
|
Re: no constants please
Richard Kelsey
(04 Jan 2004 22:59 UTC)
|
Re: no constants please
Tom Lord
(05 Jan 2004 00:50 UTC)
|
Re: no constants please
Tom Lord
(05 Jan 2004 01:19 UTC)
|
Re: no constants please
Richard Kelsey
(05 Jan 2004 11:42 UTC)
|
Re: no constants please
Tom Lord
(05 Jan 2004 16:26 UTC)
|
Re: no constants please
Richard Kelsey
(05 Jan 2004 17:49 UTC)
|
Re: no constants please
Tom Lord
(05 Jan 2004 18:24 UTC)
|
Re: no constants please
Michael Sperber
(05 Jan 2004 18:48 UTC)
|
Re: no constants please
Tom Lord
(05 Jan 2004 22:00 UTC)
|
Re: no constants please
Michael Sperber
(06 Jan 2004 07:42 UTC)
|
I don't believe in "(may GC)"
Tom Lord
(05 Jan 2004 00:55 UTC)
|
Re: I don't believe in "(may GC)"
Richard Kelsey
(05 Jan 2004 12:07 UTC)
|
Re: I don't believe in "(may GC)"
Shiro Kawai
(05 Jan 2004 12:45 UTC)
|
Re: I don't believe in "(may GC)"
bear
(05 Jan 2004 18:16 UTC)
|
Re: I don't believe in "(may GC)"
Tom Lord
(05 Jan 2004 16:35 UTC)
|
Re: I don't believe in "(may GC)"
bear
(05 Jan 2004 17:54 UTC)
|
Re: I don't believe in "(may GC)"
tb@xxxxxx
(06 Jan 2004 01:39 UTC)
|
Re: I don't believe in "(may GC)"
Michael Sperber
(06 Jan 2004 07:39 UTC)
|
Re: no constants please
Tom Lord
(05 Jan 2004 01:05 UTC)
|
Re: no constants please
Tom Lord
(05 Jan 2004 01:12 UTC)
|
Re: no constants please
Richard Kelsey
(05 Jan 2004 12:17 UTC)
|
Re: no constants please
Tom Lord
(05 Jan 2004 17:40 UTC)
|
Re: no constants please
Michael Sperber
(05 Jan 2004 19:03 UTC)
|
Re: no constants please
tb@xxxxxx
(06 Jan 2004 01:37 UTC)
|
Re: no constants please
Richard Kelsey
(06 Jan 2004 02:15 UTC)
|
Re: no constants please
Tom Lord
(06 Jan 2004 02:29 UTC)
|
Re: no constants please
tb@xxxxxx
(06 Jan 2004 02:31 UTC)
|
Re: no constants please Richard Kelsey (06 Jan 2004 03:10 UTC)
|
Re: no constants please
tb@xxxxxx
(06 Jan 2004 03:14 UTC)
|
Re: no constants please
Tom Lord
(06 Jan 2004 04:06 UTC)
|
From: xxxxxx@becket.net (Thomas Bushnell, BSG) Date: 05 Jan 2004 18:31:01 -0800 Richard Kelsey <xxxxxx@s48.org> 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