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.
Source for ticket #310
cc
changetime
2012-10-08 23:32:12
component
WG1 - Core
description
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.
id
310
keywords
milestone
owner
cowan
priority
major
reporter
cowan
resolution
fixed
severity
status
closed
summary
Rationalize start/end/(fill) arguments in sequence procedures
time
2011-12-03 03:17:54
type
defect
Changes
Change at time 2012-10-08 23:32:12
author
cowan
field
comment
newvalue
oldvalue
4
raw-time
1349713932950115
ticket
310
time
2012-10-08 23:32:12
Change at time 2012-10-08 23:32:12
author
cowan
field
resolution
newvalue
fixed
oldvalue
raw-time
1349713932950115
ticket
310
time
2012-10-08 23:32:12
Change at time 2012-10-08 23:32:12
author
cowan
field
status
newvalue
closed
oldvalue
writing
raw-time
1349713932950115
ticket
310
time
2012-10-08 23:32:12
Change at time 2012-04-10 00:20:06
author
cowan
field
comment
newvalue
oldvalue
3
raw-time
1333992006790540
ticket
310
time
2012-04-10 00:20:06
Change at time 2012-04-10 00:20:06
author
cowan
field
owner
newvalue
cowan
oldvalue
alexshinn
raw-time
1333992006790540
ticket
310
time
2012-04-10 00:20:06
Change at time 2012-04-10 00:20:06
author
cowan
field
status
newvalue
writing
oldvalue
decided
raw-time
1333992006790540
ticket
310
time
2012-04-10 00:20:06
Change at time 2012-04-09 22:02:35
author
cowan
field
comment
newvalue
The WG decided to adopt the "SRFIs" option above.
oldvalue
2
raw-time
1333983755779138
ticket
310
time
2012-04-09 22:02:35
Change at time 2012-04-09 22:02:35
author
cowan
field
status
newvalue
decided
oldvalue
new
raw-time
1333983755779138
ticket
310
time
2012-04-09 22:02:35
Change at time 2012-01-26 05:09:12
author
cowan
field
comment
newvalue
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.
oldvalue
1
raw-time
1327525752515625
ticket
310
time
2012-01-26 05:09:12
Change at time 2012-01-26 05:09:12
author
cowan
field
summary
newvalue
Rationalize start/end/(fill) arguments in sequence procedures
oldvalue
Remove start, end, fill arguments from VECTOR-COPY
raw-time
1327525752515625
ticket
310
time
2012-01-26 05:09:12
Change at time 2012-01-26 05:09:12
author
cowan
field
description
newvalue
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.
oldvalue
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 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.
raw-time
1327525752515625
ticket
310
time
2012-01-26 05:09:12