* tests/base.scm: add two tests for issue #556
The two tests are adapted from issue #556 (originally from r7rs).
The tests currently fail because errors and raised objects are
treated in the same way.
* Use different tags for raised objects and raised errors
The behaviour for raising an error (error message irritants) and
objects (raise object) are different in r7rs. So tag error objects
differently, and adjust the raised object handling to handle
the raised object instead of a list containing the raised object.
This should resolve issue #556.
* runtime: use the correct string length for comparison
Fix for the pull request adressing issue #556.
* runtime: distinguish exceptions and errors in default handler
* repl: use error-object? to decide whether an error or an exception was raised
This makes error messages a bit more informative. Also, if error objects become
a distinct type, then the repl implementation will continue to be correct. The
(deleted) second cond clause seemed to be bit redundant - I am not sure what the
original intent was.
* tests/base.scm: revert accidental deletion of else clause
* Display exceptions as errors for consistency
This changes the behaviour to match r7rs (round x) instead of C round(x).
An answer to https://stackoverflow.com/questions/32746523/ieee-754-compliant-round-half-to-even
suggests using remainder(). The following will work if FE_TONEAREST is defined, but C11
requires FE_TONEAREST to be defined if and only if the implemenetation supports it in
fegetround() and fesetround() [Draft N1570]. On the other hand, remainder() must be defined.
C23 will have roundeven(), but this is not yet available on all platforms.
The behaviour of remainder is described in Draft N1570, page 254, footnote 239.
Alternative implementation:
double round_to_nearest_even(double x)
{
#pragma STDC FENV_ACCESS ON
int mode;
double nearest;
mode = fegetround();
fesetround(FE_TONEAREST);
nearest = nearbyint(x);
fesetround(mode);
#pragma STDC FENV_ACCESS OFF
return nearest;
}
Since we now call error/loc in the macro expander, it is possible we are double-calling it if a macro is also calling it directly to report a syntax error. We need to detect that case and only add location information (line, column, filename) if it has not already been added to the error message.
