[R6RS] issue straw poll

[William D Clinger]

> Here is a straw poll covering the "non-routine" entries currently active
> in the tracking system....
> 
> Kent

--------

Footnotes (provided you read this response upside down):

Issue 7:  I'd prefer to delete or to replace the promises
of draft R6RS 20.3 than to add yet another variety.

Issue 12:  I think the SRFI editors should be consulted
on this, and we should follow their lead.  At the moment,
I suspect they haven't yet decided upon any policies for
R6RS-compatible SRFIs or reference implementations, and
I think it would be presumptive for the R6RS editors to
specify a syntax for something the SRFI editors haven't
yet agreed to support.

Issues 17, 26, 36, 42, 45, 49, 51, and 58 are related to
a formal comment I will file sometime during the first two
weeks of November.

Issue 25:  As specified by the draft R6RS, forall and exists
are not fully compatible with their alleged SRFI-1 equivalents.

Issue 45:  The proposal in the final paragraph of comment 45
is not the only way to address the concerns raised by that
comment.

Issue 46:  It appears to me that the person who wrote the
comment does not understand that the draft R6RS intends to
rewrite line separators to linefeeds.  His comment could be
interpreted as a plea to rewrite all seven sequences he
listed as linefeeds, or as a plea for get-line to recognize
all seven sequences as end-of-line markers without otherwise
changing the draft R6RS.  On my reading of the Unicode TR14
he cited, that document is primarily concerned to offer
advice to programs that perform formatting of text, which
is independent of (and IMO beyond the scope of) the draft
R6RS; all we need to decide is whether the sequences get
mapped to linefeeds or recognized by get-line.

Issue 47:  The two procedures listed in the straw poll are
not the only ways to address the concern raised by that
comment.  The person who made the comment even wrote "But
I don't really care what the committee chooses.  Any standard
sorting facility would be better than none."  If we decide
to have a destructive list sort, however, then it should go
into the mutable pairs library.

Issue 52:  I agree with the general sentiment of the comment,
but I think the best thing to do is to flush draft R6RS 16.5
and 16.6 and leave SRFI 94 as a SRFI.  If we want to provide
a facility for more convenient specification of runtime checks,
it should be a general facility not limited to numbers.

Will

--------

6  Applicable record instances
   Should we add them?
   yes/maybe/no (Y/M/N): M

7  Additional LAZY primitive for delayed evaluation
   Should we add it?
   yes/maybe/no (Y/M/N): M

9  backslash-linefeed
   Should we allow <intraline whitespace> between the \ and <linefeed>
     in \<linefeed><intraline whitespace>?
   yes/maybe/no (Y/M/N): Y

10 #;<datum> comments useless
   Should we flush?
   yes/maybe/no (Y/M/N): M

11 NaN is not a real number
   Should we make (real? <any NaN>) #f?
   yes/maybe/no (Y/M/N): N

12 R6RS library syntax should include a standard format for importing SRFI libraries
   Should we do this?
   yes/maybe/no (Y/M/N): M

14 <hex scalar value> should allow only 6 digits
   Should we limit to 6 digits?
   yes/maybe/no (Y/M/N): M
   Should we eliminate restriction on number of digits?
   yes/maybe/no (Y/M/N): M

17 "An exception might be raised" considered confusing
   Change to "An exception should not be raised"?
   yes/maybe/no (Y/M/N): M

18 String exit codes should be allowed
   Should we allow them?
   yes/maybe/no (Y/M/N): M

22 U+0085 is whitespace
   Should we make U+0085 whitespace?
   yes/maybe/no (Y/M/N): M

25 "forall" and "exists" should use SRFI-1 equivalents
   Should we rename?
   yes/maybe/no (Y/M/N): N

26 Map and for-each should work even if lists are of unequal length
   Should we make this change?
   yes/maybe/no (Y/M/N): M

27 Some generic arithmetic procedures should be put in a library
   Should we do this?
   yes/maybe/no (Y/M/N): M

36 Ambiguous call/cc-behaviour of list operations
   Should we make the benavior unambiguous?
   yes/maybe/no (Y/M/N): M

38 Position-significance of declarations in scripts
   Should we allow them only at the front of a script body?
   yes/maybe/no (Y/M/N): Y

39 Script-body differences
   Should we make script bodies like library/lambda bodies?
   yes/maybe/no (Y/M/N): M
   Should we make library/lambda bodies like script bodies?
   yes/maybe/no (Y/M/N): M

40 Exactness is orthogonal to type
   Should we eliminate statement that exactness is orthogonal to type?
   yes/maybe/no (Y/M/N): N
   Should we eliminate sections 16.5 "exact arithmetic" and 16.6 "inexact arithmetic"
   yes/maybe/no (Y/M/N): Y

42 Requirement to detect circular lists
   Should we eliminate this requirement?
   yes/maybe/no (Y/M/N): M

45 last-element behavior of for-each
   Specify return value of for-each to be the unspecified value?
   yes/maybe/no (Y/M/N): N

46 LF should not be the only line separator
   Specify larger set of line separators?
   yes/maybe/no (Y/M/N): M

47 Add (sort) and (vector-sort!) procedures
   Should we add them?
   yes/maybe/no (Y/M/N): Y

49 Higher-order procedures should not interfere with exceptions
   Should we prohibit this "interference"?
   yes/maybe/no (Y/M/N): M

51 Conflating programs and scripts
   Add a separate notion of program?
   yes/maybe/no (Y/M/N): M
   Remove <script header> from scripts?
   yes/maybe/no (Y/M/N): M

52 Exact-Integer and Real (and Complex) are more useful distinctions than Exact and Inexact
   Adopt SRFI-94 and flush 16.5 "exact arithmetic" and 16.6 "inexact arithmetic"?
   yes/maybe/no (Y/M/N): N

58 only 'big' and 'little' as endiannness may not be enough
   Should we add others or allow extensions?
   yes/maybe/no (Y/M/N): Y

[end of straw poll]