This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 310: Rationalize start/end/(fill) arguments in sequence procedures

2012-10-08 23:32:12
WG1 - Core
cowan
major
cowan
fixed
source
closed
2011-12-03 03:17:54
defect

When we approved CompleteSequenceCowan in ticket #64, we adopted SRFI 43 syntax and semantics for vector-copy, meaning that it takes optional start, end, fill arguments. This is inconsistent with various other copier procedures in R7RS as inherited from R5RS, as well as what is provided in SRFI 43 and its relatives SRFI 1 (for lists) and SRFI 13 (for strings). I see four plausible courses of action:

Do nothing (default): The only virtue here is that it requires the least thinking and editing. It's fugly and I don't want to go (or rather stay) there.

R5RS: Claw back `vector-copy` to just accept the source vector, all of which is to be copied. This provides self-consistency, consistency with R5RS, and maximum simplicity. The SRFIs will be provided as R7RS-large packages which will export the more complex and powerful versions.

SRFIs: Enhance vector-fill!, vector->list, string->list, string-copy, string-fill! to support optional start and end arguments. This provides some self-consistency, backward compatibility with R5RS, consistency with the SRFIs, and some loss of simplicity.

SRFIs-plus: Same as SRFIs, but also add optional start, end, fill arguments to list-copy and optional fill argument to string-copy. This provides maximal function, full self-consistency, backward compatibility with R5RS, and backward compatibility with the SRFIs.

summaryRemove start, end, fill arguments from VECTOR-COPYRationalize start/end/(fill) arguments in sequence procedures
descriptionWhen we approved CompleteSequenceCowan in ticket #64, we adopted SRFI 43 syntax and semantics for `vector-copy`, meaning that it takes optional ''start, end, fill'' arguments. This ticket would undo that in favor of a simple copier. SRFI 43 will be part of R7RS-large, so R7RS-large implementations would have the enhanced versions.When we approved CompleteSequenceCowan in ticket #64, we adopted [http://srfi.schemers.org/srfi-43/srfi-43.html#vector-fill-bang SRFI 43] syntax and semantics for `vector-copy`, meaning that it takes optional ''start, end, fill'' arguments. This is inconsistent with various other copier procedures in R7RS as inherited from R5RS, as well as what is provided in SRFI 43 and its relatives [http://srfi.schemers.org/srfi-1/srfi-1.html SRFI 1] (for lists) and [http://srfi.schemers.org/srfi-13/srfi-13.html SRFI 13] (for strings). I see four plausible courses of action: ''Do nothing'' (default): The only virtue here is that it requires the least thinking and editing. It's fugly and I don't want to go (or rather stay) there. ''R5RS:'' Claw back ``vector-copy`` to just accept the source vector, all of which is to be copied. This provides self-consistency, consistency with R5RS, and maximum simplicity. The SRFIs will be provided as R7RS-large packages which will export the more complex and powerful versions. ''SRFIs:'' Enhance `vector-fill!`, `vector->list`, `string->list`, `string-copy`, `string-fill!` to support optional ''start'' and ''end'' arguments. This provides some self-consistency, backward compatibility with R5RS, consistency with the SRFIs, and some loss of simplicity. ''SRFIs-plus:'' Same as ''SRFIs'', but also add optional ''start, end, fill'' arguments to `list-copy` and optional ''fill'' argument to `string-copy`. This provides maximal function, full self-consistency, backward compatibility with R5RS, and backward compatibility with the SRFIs.

I mean to say that the SRFIs will be provided in R7RS-large in any case, as WG2 has already voted them in. That part does not depend on our choice here.

statusnewdecided

The WG decided to adopt the "SRFIs" option above.

owneralexshinncowan
statusdecidedwriting
resolutionfixed
statuswritingclosed