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.
Tom Lord wrote:
Another issue of principle is type checking. The draft FFI gives
rise to many type-correct C expressions which are incorrect code:
SCHEME_CONS (SCHEME_CONS (a, b), SCHEME_CONS (c, d))>
whereas the type structure imposed by Pika conventions precludes such
errors. It is partly a subjective call whether such errors are worth
trying to get the compiler to help prevent -- but it is also partly an
empirical call and a theoretical call from human factors
considerations. Having had to fix buggy code like the above, written
by people who knew better, my subjective impression of the objective
(but unmeasured) empirical facts are that it is indeed worth getting
the compiler to help prevent such mistakes. (The Pika conventions
permit the mistake of writing x = y where SCHEME_LSET (&x, &y) is
wanted -- but there too I think we can get a vanilla C compiler to
check for such errors should it become an issue.)
I think this point is particularly important. The current draft proposal should try very hard to avoid bugs like this one, because I see a very mean thing coming up here: many popular (perhaps even the most popular?) Scheme implementations use conservative GC, under which the above will work, so people will start writing libraries for this and that, everything works fine, and the code will break on less popular but more sophisticated implementations. You don't want that. Addressing this issue would be purely syntactical, using reference parameters. cheers, felix