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

Re: [Anthony Carrico] ATTN editors: srfi document and ref implementation issues.

To: David Rush <kumoyuki@xxxxxxxxxxxxx>
Subject: Re: [Anthony Carrico] ATTN editors: srfi document and ref implementation issues.
From: Anthony Carrico <acarrico@xxxxxxxxxxxx>
Date: Wed, 14 Apr 2004 11:53:24 -0400
Cc: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, srfi-editors@xxxxxxxxxxxxxxxxx, srfi-37@xxxxxxxxxxxxxxxxx
Delivered-to: srfi-37@xxxxxxxxxxxxxxxxx
In-reply-to: <opr6fyb5h4n3pffk@xxxxxxxxxxxxxxxxxxx>
References: <y9lr7uraxsq.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <opr6fyb5h4n3pffk@xxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.5.1+cvs20040105i

On Wed, Apr 14, 2004 at 11:05:55AM +0100, David Rush wrote:

> 	1) I don't have a problem with fixing the broken HTML

I agreed that it should be fixed.

The worst case looks like a cut and paste bug that probably occurred
during finalization: double opening <html><head><html><head> tags.

Changing an SRFI, even formating, is dubious, so I recommend that the
editors consider a policy of passing finalized SRFIs through a
validator (like http://validator.w3.org/) before publication to avoid
the issue.

> 	2) I don't know what to do about the broken link

I do not recommend changing the content of the srfi. I recommend
leaving the broken links as they stand.

RATIONALE:

I doubt the editors or authors want to be in the business of changing
SRFI content, even chasing broken links (which might not be consistent
with the original).

As for SRFI 37 itself: The glibc link in question was an important
motivation for the SRFI, and was important background information
during the discussion period, but the guidelines were distilled into
the SRFI text. That text stands alone. If someone were to chase the
link, then it would be appropriate to make a note using the normal
SRFI errata process (the post finalization archive).

As for the scheme implementation links, they are specifically labeled
as preliminary versions, so it should come as no surprise if they have
changed after the srfi became final.

> 	3) I'm not sure about dropping in the new ref impl

I recommend that you do so.

RATIONALE:

Sven Hartrumpf set me private email pointed out a questionable corner
case in the ref impl. I would characterize the case in question as a
"legacy feature of my original implementation"--one that was not
specified in the SRFI. Sven and I agreed that the feature conflicts
with the SRFI treatment of operands, and so I believe it should be
treated as a bug w.r.t the SRFI. As a result, I removed it from the
distribution that I keep at:
  http://memebeam.org/free-software/args-fold/

The diff is clean. It removes the branch supporting the feature in
question. Sven and I agreed with the results of a suite of tests after
the change. I can provide Sven's email address (off the list) if you
wish to seek a second opinion on this issue.

I hope this helps with your deliberation, feel free to ask any further
questions.

Keep up the good work!

--
Anthony Carrico

Prev by Date: ATTN editors: srfi document and ref implementation issues.
Previous by thread: ATTN editors: srfi document and ref implementation issues.
Index(es):
- Date
- Thread