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.
tb> It is a known strategy for more complex memory systems to have tb> a variety of different values for certain constants. rk> Okay, but that doesn't supply an answer to either question. rk> [....] rk> This thread started with Tom Lord's statement: rk> [....] rk> tl> because, you never know, those constants might be heap allocated. rk> and then in a second message: rk> tl> Perhaps it would be clearer if I said that those constants rk> tl> may be _newly_ heap allocated. rk> I can't imagine why an implementation would allocate any of rk> these constants on the fly. tb just gave you one. rk> There is a cost to indicating that a functions or macros may rk> trigger a GC. So, basically, you don't care about threads or async execution? It's only if you don't care about those things that you need to indicate which functions may trigger GC. Otherwise, GC may occur anytime that it isn't specifically excluded. > Their uses have to be scrutinized to see which > values are live across the use. It's a total pain. Regarding which both the Pika and JNI/minor-style interfaces provide a mitigation of that pain. > I can't see declaring that SCHEME_FALSE, SCHEME_TRUE, > SCHEME_NULL or SCHEME_UNDEFINED might trigger a GC just because > there might someday exist such an implementation. You haven't given any _positive_ reasons for making exceptions of those values. Your critics are proposing only greater _regularity_ in the FFI -- that's sufficient for everything we can imagine in some future implementation. You make it sound like we're trying to drive the decision based on some hypothetical and unlikely future but really, you can reach the same conclusion we have just by deciding not to introduce gratuitous special cases in the FFI. > If someone produces an undefined-value SRFI that describes > undefined-value object containing useful data, such as Bear > has in his implementation, then it would make sense to have > a way to create such objects from C. It doesn't make sense > to do so now, when there isn't any such SRFI. Even with > such a SRFI there would be utility to having an undefined > value that could be used in places where a GC would be > undesirable. Nobody has suggested that you provide a special interface for bear-style undefineds. With a parameterless, UNDEFINED-producing function, bear could define that to good effect as a macro that implicitly passes __FILE__ and __LINE__ and the like. -t