This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: string-contains and srfi-13
- From: Jamison Hope <jrh at theptrgroup dot com>
- To: Kawa mailing list <kawa at sourceware dot org>
- Date: Wed, 4 Jan 2012 14:29:58 -0500
- Subject: Re: string-contains and srfi-13
- References: <CAHxu6d8gm8xz4PtW6-TsT21cuMOqJv91KYsSn1LY-q4yx2+HQQ@mail.gmail.com> <1669FAB6-408D-4D82-B94E-31CF3F8B7A69@theptrgroup.com>
On Dec 22, 2011, at 2:50 PM, I wrote:
This is a bug we inherited from the reference implementation. The
helper function
string-parse-start+end is documented to return three values: "rest
start end",
but within make-kmp-restart-vector (which appears about 5 levels
down in your
stack trace) its result is bound to two variables (start end). The
same error
exists in string-kmp-partial-search.
I believe that in both of those places the call to string-parse-start
+end should
be replaced by a call to string-parse-final-start+end, which strips
off the first
unwanted rest value.
OK, I was mistaken. It's actually a bug in Kawa's let-optionals*
(which I wrote,
oops), combined with a bit of under-specification in the SRFI 13
reference
documentation.
In the short term, applying my s/string-parse-start+end/string-parse-
final-start+end/g
patch will work; in the longer term, I could fix let-optionals* to
match the
authoritative behavior (as documented in the scsh source), but it
probably makes
more sense to rewrite the SRFI 13 functions to use Kawa's native
support for
#!optional arguments.
-Jamie
--
Jamison Hope
The PTR Group
www.theptrgroup.com