I don't think there's much point in exposing fatal-error as a procedure, because in general its magical effects (allowing compilers to to generate specialized code and such) will only work if it is treated as a macro. There is little point in passing it to a not-well-known procedure as an argument, for example, since there is no knowing what it actually does. Similarly, invoking it with `apply` makes little sense: you don't know what will happen to the irritants if anything, and so they might just as well be a list as an argument sequence. Unless the compiler provides interprocedural effect tracking, it will not treat fe1 or fe2, defined as (define fe1 fatal-error) and (define (fe2 . args) (apply fatal-error args)), as equivalent to fatal-error. Lastly, all your natural examples are protected by `unless` in any case, thus making them equivalent to `assume`.
So I think you should reformulate this SRFI to say that `assume` is a syntax keyword, and that it is an error to call it with #f as the value of the first argument, but it returns an unspecified value otherwise.
Here's an interesting example you might want to add:
(define (foo x a b)
(cond
((eq? x 'plus) (+ a b))
((eq? x 'minus) (- a b))
(else (assume #f))))
This definition allows a compiler to treat (foo 'times 3 5) as a compile-time error.
If you do this, then a natural SRFI title is Assume or Assumptions.
--
Go, and never darken my towels again!
--Rufus T. Firefly