ISSUE: VARIABLE-LIST-ASYMMETRY

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 1 Aug 88 20:15:41 PDT
    From: Skona Brittain <skona%csilvax@hub.ucsb.edu>

    I don't see any difference between my proposal and the
    modification to it that you are recommending.

I'm not surprised. They're the same. :-}
Sorry. I guess I didn't read carefully enough.

But I'm pretty sure I knew what threw me off, and it might be worth
correcting the style. In the problem description, you enumerate the
cases without the use of [...]. Then later you introduce the brackets,
so I was looking for

  var | (var) | (var val)

when you'd written

 var | (var [val])

etc. You might want to consider one of the following syntactic tricks
to help keep others from falling into the same trap:

 * Use notation such as the following in the problem description:
    do   & do*:            (var [init [step]])
    prog & prog*:    var | (var [init])
    let  & let*:     var | (var val)
   so that it matches the proposal.

 * Use notation such as the following in the proposal:
    do   & do*:      var | (var) | (var init) | (var init step)
    prog & prog*:    var | (var) | (var init)
    let  & let*:     var | (var) | (var init)
   in the proposal so it matches the problem description.
  
 * Say something in the running text of the proposal to make it clear
   what's going on to people like me who don't read carefully enough.
   eg,
       ``Extend the language to permit all of the following syntaxes:''

Also, the category for this change is wrong. It should be listed as an ADDITION,
not a CHANGE since it is not incompatible.

And while you're in there, I'd extend the rationale section to add the
comments I made in my last message. There are, after all, other ways you
could have gone with this proposal (such as the way I thought you were
proposing).  When the rationale section can put concern about such
alternatives to rest, I think it should.

You can add my support of the proposal to the discussion section.