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.
"Felix" == Felix Winkelmann <felix@xxxxxxxxxxxxx> writes:Felix> Am Tue, 06 Jan 2004 08:39:47 +0100 hat Michael Sperber Felix> <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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'snot 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 approachto 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 ofmicheal> 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 transformationbehind the scenes, in prologue/epilogue code that contains the C source code
the user provides) cheers, felix