On Thu, Apr 07, 2005 at 11:55:10AM -0500, Bradley Lucier wrote:
On Apr 6, 2005, at 10:47 PM, ben@fuhok.net wrote:
I also fixed a copy of small bugs --- hopefully I didn't introduce too many in their place ;-) I haven't tested these rigorously though.
s/copy/couple/
It seems to be a bit difficult to extract the bug fixes (as opposed to the other changes) from your code.
Yes, and I didn't apply them to the originals as I fixed them. In retrospect, this was not smart.
Could you list them separately? I'd like to fix my versions of the libraries.
I attached some fixes that I fished out of the rather noisy diff. I think I got most of them. The majority aren't really for `bugs', at least not serious ones. They mostly correct wrong function names in your error macros.
I noted some discrepancy in argument order between the srfi-14 text and Olin's reference implementation. For those functions that take a string and a `criterion', the srfi (usually) lists the order as `string' `criterion', but the reference implementation often switches them around. The functions string-every and string-any are exceptions: the spec orders their arguments as `criterion' `string'.
I flipped several arguments around to match the srfi spec instead of the reference implementation.
BTW, the complicated way I defined my error-checking, etc., was to make it more compatible with built-in error checking in the Gambit runtime in the hope that these libraries could someday be integrated in the runtime (either officially or de-facto).
That thought occurred to me as I was working, but as I had already started, I just plowed on. I'll use mine until yours get integrated into the Gambit distribution.
What advantage does the more complicated error checking have over the simpler checking that I put in? Is there more to it than just consistency with the Gambit runtime?
Ben