[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: 31 Dec 2003 11:49:59 -0800

   Richard Kelsey <kelsey@xxxxxxx> writes:

   > Are there any implementations of Scheme in use where SCHEME_FALSE,
   > SCHEME_TRUE, SCHEME_NULL, or SCHEME_UNSPECIFIC should be freshly
   > allocated?  Or where EQ? and == are not equivalent?  (These are not
   > rhetorical questions; I really would like to know -- is this an
   > existing or only potential problem for portability?)

   It is a known strategy for more complex memory systems to have a
   variety of different values for certain constants.  

Okay, but that doesn't supply an answer to either question.

Anyway, I just searched through SRFI-50 and found no mention
of C's ==, so I am mystified as to why it is an issue.  The SRFI
does have
  int SCHEME_EQ_P(scheme_value, scheme_value)
for invoking EQ? from C.  I could see adding
  #define SCHEME_IS_FALSE(scheme_value)		\
    (SCHEME_EQ_P(SCHEME_FALSE, scheme_value))
  #define SCHEME_IS_TRUE(scheme_value)		\
    (! SCHEME_EQ_P(SCHEME_FALSE, scheme_value))

The SRFI doesn't say that there are any values that the GC
doesn't care about; in particular it doesn't say that locations
containing SCH_TRUE, SCH_FALSE, SCH_NULL, or SCH_UNSPECIFIC
need not be registered with the GC.  They may be heap objects or
they may not.

This thread started with Tom Lord's statement:

  SCHEME_FALSE, SCHEME_TRUE, SCHEME_NULL, and SCHEME_UNSPECIFIC should
  be functions, not constants:

  Not
        x = SCHEME_FALSE;
  but:
        SCHEME_MAKE_FALSE (&x, instance);

  because, you never know, those constants might be heap allocated.

and then in a second message:  

  Perhaps it would be clearer if I said that those constants may be
  _newly_ heap allocated.

I can't imagine why an implementation would allocate any of
these constants on the fly.  Even if you had a system which
had multiple versions of them and the associated complicated
EQ? (which I still don't believe will ever happen), why on 
Earth would you allocate the new copies on the fly?

There is a cost to indicating that a functions or macros may
trigger a GC.  Their uses have to be scrutinized to see which
values are live across the use.  It's a total pain.  I can't
see declaring that SCHEME_FALSE, SCHEME_TRUE, SCHEME_NULL or
SCHEME_UNDEFINED might trigger a GC just because there might
someday exist such an implementation.

If someone produces an undefined-value SRFI that describes
undefined-value object containing useful data, such as Bear
has in his implementation, then it would make sense to have
a way to create such objects from C.  It doesn't make sense
to do so now, when there isn't any such SRFI.  Even with
such a SRFI there would be utility to having an undefined
value that could be used in places where a GC would be
undesirable.
                                       -Richard