[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: no constants please

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