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 503: Setters should be allowed to return zero values

2013-07-07 03:20:44
WG1 - Core
alexshinn
major
cowan
wontfix
source
closed
2013-05-13 00:24:57
defect

Andy Wingo writes:

There are also a number of minor points about the WG1 draft that I feel were not dealt with in a satisfactory way. A few things come to mind: [...] the insistence on "an unspecified value" rather than allowing 0 values.

Alaric Snell-Pym, Emmanuel Medernach, and Aaron Hsu made similar remarks.

R6RS provides this option, allowing setter-type procedures as well as set! itself to return an unspecified number of unspecified values. The WG, however, was swayed by the argument of Alex Shinn that allowing zero values to be returned means that completely unknown procedures cannot be safely called except by wrapping each call in a call-with-values.

In principle, this problem cannot be eliminated as long as returning multiple values is possible at all, but eliminating the theoretical possibility of standard setter procedures to return other than one value (something which no R6RS implementation actually does) makes it less likely to occur.

descriptionAndy Wingo writes: There are also a number of minor points about the WG1 draft that I feel were not dealt with in a satisfactory way. A few things come to mind: [...] the insistence on "an unspecified value" rather than allowing 0 values. R6RS provides this facility, allowing setter-type procedures, as well as `set!` itself, to return an unspecified number of unspecified values. The WG, however, was swayed by the argument of Alex Shinn that Andy Wingo writes: There are also a number of minor points about the WG1 draft that I feel were not dealt with in a satisfactory way. A few things come to mind: [...] the insistence on "an unspecified value" rather than allowing 0 values. Alaric Snell-Pym made a similar remark. R6RS provides this facility, allowing setter-type procedures, as well as `set!` itself, to return an unspecified number of unspecified values. The WG, however, was swayed by the argument of Alex Shinn that allowing zero values to be returned means that completely unknown procedures cannot be safely called except by wrapping each call in a `call-with-values`. In principle, this problem cannot be eliminated as long as returning multiple values is possible at all, but eliminating the theoretical possibility of standard setter procedures to return other than one value (something which no R6RS implementation actually does) makes it less likely to occur.
descriptionAndy Wingo writes: There are also a number of minor points about the WG1 draft that I feel were not dealt with in a satisfactory way. A few things come to mind: [...] the insistence on "an unspecified value" rather than allowing 0 values. Alaric Snell-Pym made a similar remark. R6RS provides this facility, allowing setter-type procedures, as well as `set!` itself, to return an unspecified number of unspecified values. The WG, however, was swayed by the argument of Alex Shinn that allowing zero values to be returned means that completely unknown procedures cannot be safely called except by wrapping each call in a `call-with-values`. In principle, this problem cannot be eliminated as long as returning multiple values is possible at all, but eliminating the theoretical possibility of standard setter procedures to return other than one value (something which no R6RS implementation actually does) makes it less likely to occur.Andy Wingo writes: There are also a number of minor points about the WG1 draft that I feel were not dealt with in a satisfactory way. A few things come to mind: [...] the insistence on "an unspecified value" rather than allowing 0 values. Alaric Snell-Pym and Emmanuel Medernach made similar remarks. R6RS provides this option, allowing setter-type procedures as well as `set!` itself to return an unspecified number of unspecified values. The WG, however, was swayed by the argument of Alex Shinn that allowing zero values to be returned means that completely unknown procedures cannot be safely called except by wrapping each call in a `call-with-values`. In principle, this problem cannot be eliminated as long as returning multiple values is possible at all, but eliminating the theoretical possibility of standard setter procedures to return other than one value (something which no R6RS implementation actually does) makes it less likely to occur.
descriptionAndy Wingo writes: There are also a number of minor points about the WG1 draft that I feel were not dealt with in a satisfactory way. A few things come to mind: [...] the insistence on "an unspecified value" rather than allowing 0 values. Alaric Snell-Pym and Emmanuel Medernach made similar remarks. R6RS provides this option, allowing setter-type procedures as well as `set!` itself to return an unspecified number of unspecified values. The WG, however, was swayed by the argument of Alex Shinn that allowing zero values to be returned means that completely unknown procedures cannot be safely called except by wrapping each call in a `call-with-values`. In principle, this problem cannot be eliminated as long as returning multiple values is possible at all, but eliminating the theoretical possibility of standard setter procedures to return other than one value (something which no R6RS implementation actually does) makes it less likely to occur.Andy Wingo writes: There are also a number of minor points about the WG1 draft that I feel were not dealt with in a satisfactory way. A few things come to mind: [...] the insistence on "an unspecified value" rather than allowing 0 values. Alaric Snell-Pym, Emmanuel Medernach, and Aaron Hsu made similar remarks. R6RS provides this option, allowing setter-type procedures as well as `set!` itself to return an unspecified number of unspecified values. The WG, however, was swayed by the argument of Alex Shinn that allowing zero values to be returned means that completely unknown procedures cannot be safely called except by wrapping each call in a `call-with-values`. In principle, this problem cannot be eliminated as long as returning multiple values is possible at all, but eliminating the theoretical possibility of standard setter procedures to return other than one value (something which no R6RS implementation actually does) makes it less likely to occur.
resolutionwontfix
statusnewclosed

The WG decided by unanimous consent to take no action on this ticket.