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

Re: SRFI 62: S-expression comments (fwd)

This page is part of the web mail archives of SRFI 62 from before July 7th, 2015. The new archives for SRFI 62 contain all messages, not just those from before July 7th, 2015.

(If you have a message regarding the SRFI, please send it to the SRFI
62 discussion list or srfi-discuss@, not just me directly.)

On Thu, 6 Jan 2005, Christopher Dutchyn wrote:

> On Thu, 6 Jan 2005, Taylor Campbell wrote:
> > I didn't notice that S-expression comments were to be in R6RS already,
> > but R6RS is at least a year away,
> Your SRFI is at least 2 months away, based on the process timeline.

That is a true statement.  That it is pointless has not been ruled out.
What does that matter?

> > and I think it is better to have things already in SRFIs before R6RS is 
> > released, so the transition to R6RS will be slightly easier.
> Sure; except that the SRFI people then have to spend time monitoring it 
> for its status wrt R*RS.

I'm not sure what you mean here.  The SRFI editors don't necessarily
have anything to do with the R6RS committees, and, if I'm not mistaken,
there is no overlap between the SRFI editors & the R6RS committees.

> > I'm not sure why you felt this comment any less pointless than the SRFI 
> > itself anyway:
> Two reasons: I want to avoid wasting time -- this proposal adds work to 
> many schedules:

Your email adds work to my schedule because I chose to pay attention to
it.  Your email added work to your schedule because you chose to send
it.  The amount of time & work added, however, is negligible, just like
with the SRFI document.

>      * implementors will want to examine and document whether they support it,

Many implementations already support it.  It is a trivial extension
that is trivial to implement.  I doubt whether any implementors don't
know whether their implementations support it or not.

>      * SRFI editors will monitor R*RS status,

Again, I don't understand what you mean here.

>      * programmers will examine both to see if there's any material difference.

Looking at a SRFI document takes a completely insignificant amount of
time, especially when the specification is so short as in this SRFI.

> Further, as your proposal will become redundant soon thereafter; it will 
> add to confusion.

What confusion does minor redundancy bring?  It is likely that more
than just this SRFI will be incorporated into R6RS, yet I don't see you
-- yet, perhaps -- trying to eliminate those SRFIs that are.

> > If you don't have any objections to it, it will be finalized anyway. 
> > (If you do have some objections to it, the R6RS committees might pay 
> > attention.)
> Having it be withdrawn based on the note that it will be part of R6RS 
> seems best IMHO.

I gathered that already.  Being the author of the SRFI, however, my
disagreement with that holds more weight than your humble opinion, and
you have not convinced me otherwise.  (In my humble opinion, such a
trivial matter that you have brought up is pointless.  I doubt whether
you care much about that opinion, however.)