chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] [PATCH][5] Fix types.db entries after SRFI-1 and SRFI-


From: Peter Bex
Subject: [Chicken-hackers] [PATCH][5] Fix types.db entries after SRFI-1 and SRFI-13 removal
Date: Mon, 10 Aug 2015 21:04:44 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi all,

On IRC, we got into a discussion about list operators and I noticed that
types.db still holds type definitions for the SRFI-1 and SRFI-13
"extended" versions of standard procedures "member", "assoc" and
"string-fill!" (actually, "string-fill!" was simply commented out).

I have restored these to match the R5RS core versions in the attached
patch.  I don't know whether this needs to be/can be fixed in CHICKEN 4,
because there are no library prefixes, so the scrutinizer is unable to
distinguish between "member" from the "scheme" module and "member" from
the "srfi-1" module...(?!)

At least now compiling the following program gives a warning at compile
time instead of just raising an exception at run time:

  (print (assoc 1 '((1 1) (2 2) (3 3)) equal?))

I've also added a comment to "rassoc" from data-structures, because its
current type signature mirrors the extended SRFI-1 version of "assoc",
which is a little strange considering that's not part of CHICKEN core
anymore.  I think it should probably be redefined to work exactly like
"assoc" (so remove the predicate argument).  This would allow it to be
implemented as an inline operator in C, like C_i_assoc, which should be
quite a bit faster.  On the other hand, who uses rassoc anyway?  Besides,
having the comparison predicate default to "eqv?" instead of "equal?",
like assoc, is extra bizarre so we might just as well get rid of the
thing.

Cheers,
Peter

Attachment: 0001-Restore-type-definitions-for-pure-R5RS-versions-of-S.patch
Description: Text Data

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]