Hi Wolfgang, > I haven’t had a chance to review the SRFI in depth yet, but I noticed > that it does not specify (beyond the infamous “it is an error”) what > happens when a type-check fails. This is a problem. There’s little > point in checking values if the implementation can happily ignore > failures—which is allowed in this case, per R7RS semantics.
Several reasons: - Accommodation of existing implementation behavior. Chicken, for example, ignores type annotations in interpreter mode, only checking them during compilation. - Allowing undefined behavior for heavily-optimized implementations (like Stalin if I manage to contribute this SRFI there; or Pre-Scheme, where I'm trying to contact the maintainer for collaboration.) - Allowing to omit the (potentially expensive) checks for production builds, only checking in debug mode. > I strongly suggest that a failed type check should cause an exception > with type &assertion to be raised. (People who know more about R6 > than I do may be able to suggest a more specific condition type.) &assertion is the suitable exception, I believe. The sample implementation uses assert whenever possible too. But I'm too wary of mandating it (for reasons above), thus under-specification of error type/conditions. Thanks for caring about that! -- Artyom Bologov https://aartaka.me
