Comments on draft #3 Wolfgang Corcoran-Mathe (05 Aug 2026 19:09 UTC)
Re: Comments on draft #3 Peter McGoron (05 Aug 2026 21:54 UTC)

Comments on draft #3 Wolfgang Corcoran-Mathe 05 Aug 2026 19:09 UTC

Hello Peter and the SRFI 274 list,

I’ve successfully run the sample implementation tests on my build
of chibi 0.12.

A few mostly editorial comments on the third draft.  Forgive the
pedantry.  Edits are in square brackets.

# Rationale

* “These arguments allow one to copy segments of the string/vector
  without having to write an explicit loop for it.”  Omit “for it”.

* Some grammatical awkwardness here: “But by allowing a selection of a
  portion of a list, the start and end arguments run into specification
  issues when passed improper lists.”  The start & end arguments don’t
  allow anything, and they aren’t passed anything, either.  Change to
  something like “But if these procedures are allowed to select a
  portion of a list, how should they interpret their start and end
  arguments when that list is improper?”

* “The common implementation of many procedures, …, work[s] fine with
  improper lists.”

* “… they don't care if [the] list is proper after those elements.”

* Agreement fixes: ‘[Examples] of this behavior [are given in] the
  “implementation responsibilities” sections of many procedures in the
  R6RS, which include statements like …’

* “This means that [copying a dotted list] to [the] endth pair (whose
  cdr is neither a pair or the empty list) is the same as copying …”

# Specification

* “An improper list is a sequence of zero or more cons cells that
  [does] not end in an empty list.”

* “[Every] non-pair and non-null object is a zero-length improper list.”

* I hate to raise this issue again, but are you committed to using “it
  is an error” in this SRFI?  I understand that it modifies things from
  R7RS-small, where “it is an error” has currency.

* “[Except in the case] of list-copy, if start is omitted, …”

* The Editorial conventions paragraph on square brackets is a little
  hard to understand, although the idea is familiar.

* Applying ‘list-tail’ to *im-list* arguments would seem to be an
  error in R7RS-small, where ‘list-tail’ takes a *list* argument.
  I think the equivalent of ‘list-copy’ called without an *end* is
  (list-copy (drop im-list start)), since ‘drop’s first argument can be
  anything.

## list-copy

“… and the [new / returned / resulting] list is terminated with an
empty list.”

## list->vector

Consistency: “Returns a newly [allocated] vector”.

## R7RS Large SRFI procedures

The dual-SRFI-number library names (like (srfi 274 41)) are rather
horrible, but I don’t have a better solution at the moment.

Thanks for your work on SRFI 274 and all your other SRFIs.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>