This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hello everybody. I just realized, that the R*RS predicates complex?, real?, rational? and integer? don't have an C equivalent. These are probably easily provided. However, there is also need for a test, whether a Scheme number is convertible to a C builtin number type. I assume that such a test will only be required in combination with the actual conversion. Therefore, I suggest the following solution: long gh_scm2long(SCM obj); /* the current function */ long gh_safe_scm2long(SCM obj, int* flags); /* the new function */ The status of the conversion could be returned in the flags variable. (Instead of int, an enumeration could be used, or a typedef, ...) One could even think of removing the old conversion function and only use the alternative solution: If the user is not interested in the flags, a NULL pointer can be passed. An implementation could look like (the internal conversion functions should obviously be renamed and not belong to the gh_ interface): inline long gh_scm2long(SCM obj, int* flags) { if (flags) return gh_safe_scm2long(obj, flags); else return gh_unsafe_scm2long(obj); /* the old function, renamed */ } With an optimizing compiler, there is no overhead between the current call gh_scm2long(o) and the changed call gh_scm2long(o, NULL). It's a matter of taste, but I think this would be the cleanest solution, although it would break existing code. Flags could be (possibly in combination): OVERFLOW, SIGNEDNESS, TYPE_MISMATCH, ... Not all of these have to be errors: For example, a TYPE_MISMATCH could mean that a rational was converted to a long. Guile could provide a sensible default (e.g. the quotient) and still report the TYPE_MISMATCH (the quotient, however, could lead to an OVERFLOW). Similar for Scheme-real --> long etc. Best regards, Dirk Herrmann