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.
Richard Kelsey <kelsey@xxxxxxx> writes: > Look, the problem here is easy: > > 1) Your SRFI demonstrably loses on certain kinds of implementations; > 2) There is a minor change which will make it not lose. > > Why on earth not prefer number (2)???? > > Clue me in. What is the minor change? A lot of different > suggestions have been made. It's like you blow up a building and then complain that there's too much dust to accurately say anything has been damaged at all. "Show me the damaged part of the building." I can't, the building is gone. You need a calling convention that allows for implementations to use *ANY* garbage collection regime they choose. You need a calling convention that allows for implementations to use *ANY* style of threads implementation they choose. You need a syntax that allows implementations to implement eq? and #f in *ANY* manner they choose. Repeatedly, you have chosen a view about what makes the C code prettier which stomps on various ones of these. Prettiness is fine, but not to sacrifice correctness. Your out, each time, has been to say something like "I'm only interested in this or that subset", and the result is a wasted SRFI. SCHEME_FALSE should not be assumed to be a C constant; you cannot assume that eq? and == are the same; you cannot assume that you have complete control over when other threads run. There are known ways to write an FFI that do not have these problems, that are not inefficient, and that work JUST FINE. With nearly every other SRFI, the point is supposed to be "any scheme system that has the relevant facility can implement this"; but yours is "any scheme system that is sufficiently simplistic can implement this". The exact opposite! You have declared your apparent belief that taking the address of a function in C is some kind of witchcraft. What gives? Thomas