SRFI 157 draft 2 comments
Sudarshan S Chawathe 10 Aug 2017 03:10 UTC
I enjoyed reading this SRFI very much. Below are a few comments, mostly
minor [Ref. "Draft #2 published: 2017/7/29"].
- In the test-tail-position example, should the "tail"s in the
let-syntax be "tail?"s?
- with-continuation-mark: I am not sure whether there is supposed to
be an ordering in the evaluation of <key> and <value>. I would
guess not, but an explicit statement either way would be helpful.
- In continuation-mark-set->list*, perhaps the fixed value of #f to
indicate a missing value for a mark could be replaced with a more
general default, similar to what is used for hash tables in SRFI 69,
etc. (so that programs may easily use #f as a mark's value). A
similar comment applies to continuation-mark-set-first and
call-with-immediate-continuation-mark.
- In the sample implementation, file lib/inferior/expression.scm, the
four definitions immediately following the comment "Named let" are
duplicated.
- In the sample implementation, file lib/inferior/unspecified.scm,
"unspecified?" is used both as a predicate for the "<unspecified>"
record-type and as a name for a separately defined procedure. I am
not sure if this is allowed by R7RS. (Kawa complains, but Larceny
does not, in my very limited testing.)
- Minor points:
- An earlier note that a continuation mark is conceptually a
key-value pair associated with a frame, with keys compared using
eq?, would be helpful (for better understanding of the examples, in
particular).
- current-continuation-marks: The description mentions
continuation-mark-set->list and continuation-mark-set-first, but not
continuation-mark-set->list*, which seems a bit odd, although the
implication is probably clear enough.
- Perhaps "continuation-mark-set" could be replace with
"continuation-marks" in the procedure names. I think the latter is
simpler and matches the names "current-continuation-marks" and
"continuation-marks?" better, though I can also see value in
sticking with the names used by Racket.
- (very minor) In the factorial example (which is very nice), a
distinction could perhaps be drawn between "procedures and
processes they generate" (using terminology from the "Structure
and Interpretation of Computer Programs" book) in the context of
recursion v. iteration . Even more minor, the correspondence
between fact1 and fact2 could be made even more obvious by using a
named-let in fact1.
Regards,
-chaw