Andy Wingo <wi...@pobox.com> writes:
> I did apply it, but it made the test cases start to fail, because
> numbers.test is loaded after ecmascript.test, and:
>
> scheme@(guile-user)> ,L ecmascript
> Happy hacking with ECMAScript! To switch back, type `,L scheme'.
> ecmascript@(guile-user)> true * true;
> $1 = 1
> ecmascript@(guile-user)> ,L scheme
> Happy hacking with Scheme! To switch back, type `,L ecmascript'.
> scheme@(guile-user)> (* #t #t)
> $2 = 1
Oh, I see. Your implementation of ecmascript extends `*' to work on
booleans, is that right? If so, then I think it naturally follows that
(expt <bool> K) should also work.
If there were a test case in numbers.test to verify that (* #t #t)
throws an exception (a test no less reasonable than (expt #t 2)), then
ecmascript would break that too, even without my recent patch.
I think it would be okay to simply remove the (expt #t 2) and
(integer-expt #t 2) tests.
> I think that's the thing, anyway. It just sounds really squirrelly.
> Could you not extend `expt' or `integer-expt' instead?
In a sense there is no need to extend any of the arithmetic operators.
We could just force people to make their own operators like `g+', `g*',
etc.
The advantage of being able to extend the normal operators is that
existing code that uses `+', `*', `expt', etc, can work with any new
data type you later add. It allows the whole system to be extensible.
I think that's a huge win.
Mark
