> I was wondering if it is admissible for the "error" procedure
> to be defined using the "raise" primitive of SRFI 21:
>
> (define (error msg . args)
>   (raise (make-error-exception msg args)))
>
> where "make-error-exception" is implementation dependent.
>
> I would like this to be explicitly permitted.

Agreed. It will be added in the upcoming revision.
Note that this definition accepts more than 1 argument, which
is currently not required. But I am leaning towards the proposal of
Felix.

> So in fact my question is: what does it mean to "signal an error"?

It's a term I lifted from R5RS. According to R5RS, it means
that "implementations must detect and report the error".
"Reporting" an error could, IMHO, involve calling an error handler,
otherwise every Scheme with error handling capability would
be in violation of the standard.

My intention was that the implementation does the same thing
as it does when a built-in procedure "signals an error".

> I think it can't require printing an error message, because even
> this is hard to specify (is the standard output used or standard
> error?  what if there is no stdout and stderr?  can a window
> with the error message pop up?  on what display?  can the printer
> be used?  etc).

What about:
"The procedure error will signal the error `msg', as described in R5RS.
 Whatever happens exactly when an error is signalled is left to the
implementation, but a reasonable
 behaviour might be to display `msg' and either terminate the
application (for a batch compiler)  or go back to the
read-evaluate-print loop (for an interactive implementation). It is also
explicitely allowed that the error is intercepted by some
implementation-specific error handling mechanism, for example by the
`with-exception-handler' procedure in SRFI-21."

Stephan