Email list hosting service & mailing list manager

(Previous discussion continued)
Re: no constants please Richard Kelsey (04 Jan 2004 18:09 UTC)
Re: no constants please felix (04 Jan 2004 19:28 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 20:06 UTC)
Re: no constants please Tom Lord (04 Jan 2004 21:39 UTC)
Re: no constants please Tom Lord (04 Jan 2004 22:09 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 22:58 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:16 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:45 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 11:40 UTC)
Re: no constants please Tom Lord (05 Jan 2004 16:51 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 17:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:50 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 18:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 22:26 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 01:21 UTC)
Re: I don't believe in "(may GC)" Richard Kelsey (05 Jan 2004 12:06 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 17:00 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 17:53 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:31 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:38 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 12:16 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:05 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:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 02:55 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 02:31 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 03:09 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 03:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 04:32 UTC)

Re: no constants please Richard Kelsey 06 Jan 2004 03:09 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