> - Maybe the C functions C_inexactp and such should be the ones that raise > the exception, rather than the Scheme code? I don't know where else > they are used or what's most consistent/clean.
I would recommend to keep error-checking code out of the C runtime part as much as possible. This allows the C primitives to be used in an unsafe context, reduces the overall body of C code used and is easier to maintain. > - The rewrites in c-platform.scm seem kind of redundant with the rewrites > done by the scrutinizer and possibly wrong for these cases too, so > another potential hiding place for many bugs. > Now that we have the scrutinizer I think they can probably be removed > altogether without loss of performance in compiled code. This should > also result in faster compilation times since the rewriting code seems > rather complicated too (and it's hard to understand, so getting rid of > it is probably a good idea maintenance-wise too). > I'm just not sure whether all functionality is truly duplicated in > types.db. Of course if we remove it, this should wait until after > 4.8.0 is released. I agree completely. Specialization makes many rewrites unnecessary. > - I noticed that with -O4, the following code passes cleanly: > > (define-syntax assert-fail > (syntax-rules () > ((_ exp) (assert (handle-exceptions ex #t exp #f))))) > (assert (exact? 1)) > (assert (not (exact? 1))) > (assert-fail (exact? 1)) > > Could someone explain how this is possible? -debug o didn't > really help, nor did ripping the rewrites from c-platform.scm "assert" expands into "##core#check", which is removed in unsafe mode. cheers, felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
