Email list hosting service & mailing list manager

SRFI 157 draft 2 comments Sudarshan S Chawathe (10 Aug 2017 03:10 UTC)
Re: SRFI 157 draft 2 comments Marc Nieper-Wißkirchen (10 Aug 2017 06:44 UTC)
Re: SRFI 157 draft 2 comments Marc Nieper-Wißkirchen (12 Jan 2018 20:18 UTC)

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