[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.

Am Tue, 06 Jan 2004 11:24:14 +0100 hat Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> geschrieben:

"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
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)