Am Tue, 06 Jan 2004 10:22:13 +0100 hat Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> geschrieben:

>>>>>> "Felix" == Felix Winkelmann <xxxxxx@proxima-mt.de> writes:
>
> Felix> Am Tue, 06 Jan 2004 08:39:47 +0100 hat Michael Sperber
> Felix> <xxxxxx@informatik.uni-tuebingen.de> geschrieben:
>
>>> Let me rephrase: In what kind of environment would "hairy"
>>> *necessarily* imply "GC-causing"?
>
>>> (There used to be a version of Scheme 48 where the equivalent of
>>> SCHEME_EXTRACT_LONG could cause a GC because it could do a callback.
>>> This was an implementation convenience, not a necessity, and it's gone
>>> now.)
>
> Felix> Well, good for you! But what should other implementations do?
>
> I asked a question here.  (As Richard and I did many times.)  You
> answer with a counter-argument to something I didn't even say.  It
> would greatly help if someone answered the question instead.
>

Ok, to repeat it very slowly:

tom>    If I'm using some exotic number representation (constructive reals,
tom>    perhaps), then EXTRACT_DOUBLE may very well involve some pretty
hairy,
tom>    hence possibly GC-causing, computation.

As far as I understand it, Tom is talking about the situation that
extracting the DOUBLE may cause GC (He calls this "hairy", but that's
not relevant, what's relevant is that it's "possibly G-causing", contrary
to what
the current draft proposal assumes). Note that this may apply to
other types as well.
The point is that nearly every primitive in the current draft proposal
may in certain implementations involve possible GC invocations.

richard> This doesn't worry me too much; there aren't a lot of such
richard> implementations around.

So Richard basically doesn't care about non-simplistic implementations.
Ok, that's a valid point of view. It's just surprising, since the SRFI
webpage says:

`The "Scheme Requests for Implementation" (SRFI) process is a new approach
to helping Scheme users to write portable and yet useful code. It is a
forum
                                  ^^^^^^^^
for people interested in coordinating libraries and other additions to the
Scheme language between implementations.'
                 ^^^^^^^^^^^^^^^^^^^^^^^

Or does this apply only to "blessed" implementations?

michael> Let me rephrase: In what kind of environment would "hairy"
michael> *necessarily* imply "GC-causing"?

In an environment where the primitive (like SCHEME_EXTRACT_DOUBLE)
involves non-trivial operations, perhaps because of Scheme-level
hooks, or because if subclassing (SCHEME_RECORD_P comes to mind),
or for other reasons like some original data representation is used.

michael> (There used to be a version of Scheme 48 where the equivalent of
micheal> SCHEME_EXTRACT_LONG could cause a GC because it could do a
callback.
micheal> This was an implementation convenience, not a necessity, and it's
gone
micheal> now.)

So what? In S48 this was an implementation convenience. It wasn't a
necessity,
ok. But on *other* implementations it may very well be (not necessarily
the equivalent of SCHEME_EXTRACT_LONG, but perhaps SCHEME_EXTRACT_DOUBLE,
or SCHEME_RECORD_P, or SCHEME_SET_CAR, or whatever).

(My answer to this problem would be: completely perform the transformation
behind the scenes, in prologue/epilogue code that contains the C source
code
the user provides)

cheers,
felix