[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some typos and trivial comments
I've noticed a few typos in the text of SRFI 40 that I'd like to point out
before finalization. Also I have some comments and questions on the
presentation, most of which are trivial.
I'll refer to the file currently at
http://srfi.schemers.org/srfi-40/srfi-40.txt by line number below.
Line 11: I think you should mention that the SRFI defines even streams in the
abstract. You state this on line 223, but I think that's too late.
Line 147: "Shown below is a Scheme implementation of Figure 3 from the paper,
with the (delay (force ...)) hidden within stream-define, which is the syntax
used to create a function that returns a stream:"
I think it should be mentioned that scheme-define is used only in the "easy"
case, and not needed for "even" or "odd" streams. I got confused and went
looking for stream-define in the specification. Also, should it read "Shown
below are Scheme implementations of Figure 1-3 from the paper"?
Line 261: stream-from is never mentioned outside of its use here. I believe
(stream-from 0) should read from0, which you define later in the text.
Line 377: Left hand side of => is missing a paren.
Line 445: Left hand side of => is missing a paren.
Line 466: Left hand side of => is missing a paren.
Line 474: "The reference implementation relies on the record types of SRFI-9
and should instead use whatever mechanism the native Scheme system uses to
create new types."
To me this reads as saying SRFI-9 records are somehow deficient for use in
implementing streams, which I don't see as being the case. Perhaps this could
read "The reference implementation relies on the record types of SRFI-9.
Implementations may instead use whatever mechanism the native Scheme system
uses to create new types."
Line 477: "The following names not specified in this SRFI are used in the
Some of these names are not defined in the reference implementation (eg. and,
result-stream->output-stream-helper-1), some need not be (eg. any, see note
below on using SRFI 1) and some that are defined are not listed (eg. every).
Rather than explicitly list the names which should not be considered part of
the API, since obviously it is easy to get wrong, I think you should state
something along the lines of "all identifiers defined in the reference
implementation not appearing in the specification section of this document
should not be considered part of the API and implementations should not expose
those identifiers to the programmer if possible".
Line 486: "The implementation of stream-unfoldn attempts to solve the
safe-for-space problem as cleanly and portably as possible. The final
implementation is derived from this naive code:"
I have trouble seeing how the incremental code you give leads to the code
included in the reference implementation. Perhaps this needs a revision to
bring it up to date with the reference implementation. Or perhaps you could
just comment on the safe-for-space problem and relegate this discussion of
implementation strategies to the discussion archive. Or maybe I'm misreading
Line 645: You define the functions `any' and `all'. Why not rely on the
semantics of `any' and `every' as defined in SRFI 1?
Overall I think this is a very good SRFI and I look forward to its finalization.