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 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.
Ah, so you mean "are there currently implementations that do X?", is that correct? Why don't you say so? ;-) In Gauche, SCHEME_RECORD_P may gc (re-read Shiro's post, if you like). It's just one example. What's important is that you shouldn't restrict implementations. Tomorrow some implementor may decide to make all primitive data be subclassable. If you design a portable SRFI, you have to anticipate how it's going to influence future implementations, or future extensions to existing implementations. Since they *are* alternatives to the current draft proposal (alternatives which have already been given) I don't understand why the SRFI-50 authors cling so desperately to the current specification. All reasons so far have been - it's syntactically nicer (unimportant, FFI code is going to be ugly anyway, no matter how much you try) - it's more efficient (highly subjective, and probably simply not true. Unless somebody starts doing benchmarks we should try to make FFI code reliable, safe, and simple) - we don't care about the alternatives, we don't care about exotic implementations (well, no comment) cheers, felix