[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: duplication of SRFIs
- To: srfi-78@xxxxxxxxxxxxxxxxx
- Subject: Re: duplication of SRFIs
- From: Alex Shinn <alexshinn@xxxxxxxxx>
- Date: Mon, 14 Nov 2005 12:20:12 +0900
- Delivered-to: srfi-78@xxxxxxxxxxxxxxxxx
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HIBFp8gOh+zo36GouAbMMZkZ6yFYqWNmZqZRyOGaAXFAh48mLDe5ApmGY94AzGTZ4LUYz0yDfgdtKurWnpfPWQ62CWEwJH690oo/0MwTJ0f+v3D6n58HkK2FlsdOemK1/19CmcperQtRbS89+mQcec1x/IJ9bCJ4+sorVDIwc+Y=
Per Bothner wrote:
> Of course the SRFI processes *allows* duplicate "standards",
> but clearly that should be undesirable, except in the case of
> documenting existing practice. That is not the case with
> SRFI-64 vs -78, as far as I know.
Well, there are many reasons to have duplicate standards, including
fundamentally incompatible designs, and arguably a certain amount of
healthy competition among SRFIs is a good thing.
On the other hand, it's not clear to me what the purpose of SRFI-78
is as opposed to SRFI-64. It claims to be lightweight yet adds a
CHECK-EC form, which is unnecessary, pulls in a requirement for
SRFI-42, and doesn't seem to offer much more than running tests
inside an existing comprehension available once you are using
SRFI-42. In exchange it removes any handling of exceptions, which
seems to be rather crippling for a test SRFI.
One might argue that the groups and filtering capabilities of SRFI-64
are heavy, and thus desire a trimmed down version, but in that case
it would be nice to use a compatible subset, as in the formatting
SRFIs 28 and 48. You could even participate in the ongoing SRFI-64
discussion where the author has indeed been very receptive to
suggestions.
--
Alex