Email list hosting service & mailing list manager

(Previous discussion continued)
Re: I don't believe in "(may GC)" Felix Winkelmann (06 Jan 2004 10:46 UTC)

Re: I don't believe in "(may GC)" Felix Winkelmann 06 Jan 2004 10:46 UTC

Am Tue, 06 Jan 2004 11:24:14 +0100 hat Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> geschrieben:

>>>>>> "Felix" == Felix Winkelmann <xxxxxx@proxima-mt.de> writes:
>
> Felix> Am Tue, 06 Jan 2004 10:22:13 +0100 hat Michael Sperber
> Felix> <xxxxxx@informatik.uni-tuebingen.de> 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