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