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