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

Re: I don't believe in "(may GC)"

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.




On Tue, 6 Jan 2004, Michael Sperber wrote:

>>>>>> "Felix" == Felix Winkelmann <felix@xxxxxxxxxxxxx> writes:
>
>Felix> Am Tue, 06 Jan 2004 10:22:13 +0100 hat Michael Sperber
>Felix> <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> geschrieben:
>
>michael> Let me rephrase: In what kind of environment would "hairy"
>michael> *necessarily* imply "GC-causing"?
>
>Felix> In an environment where the primitive (like SCHEME_EXTRACT_DOUBLE)
>Felix> involves non-trivial operations, perhaps because of Scheme-level
>Felix> hooks, or because if subclassing (SCHEME_RECORD_P comes to mind),
>Felix> or for other reasons like some original data representation is used.
>
>I asked a question of the type "In what kind of environment would X
>hold?"  Your answering "in an environment where X holds."
>Technically, that's an answer to my question.  Just not a useful one.


I already mentioned two specific examples of widely-used implementations
where something other than a hardware-width double is used to hold
inexact reals.  Either of them would need to create call frames to
execute subroutines and expressions to get a double.  Creating call
frames involves allocating memory.  Allocating memory, eventually,
involves calling GC.

I am using a scheme (though not a widely used one) where getting
characters from a string involves traversing a tree.  The traversal
requires nontail recursive calls, and needs to allocate call frames
for them.  For my purposes this is _BETTER_ than the cstring style
strings in common use, and I fully expect that a number of implementors
will want to do this in the future. If getting characters is allowed
to GC, they won't have to give up your FFI in order to do it.

				Bear