[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Reliability



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