Am 27.07.2011 17:11, schrieb Alex Shinn:
> On Wed, Jul 27, 2011 at 9:34 PM, Denis Washington<denisw@online.de>  wrote:
>>
>> I haven't found anything to complain about in chapter 3, so here are my
>> comments on the fourth chapter:
> [...]
>
> Thank you very much for the extensive comments.  We have
> indeed not paid much attention to improving the prose yet,
> focusing instead on features and semantics.  If editorial
> changes are all that remain I think we're on good track for
> the final draft.

You're welcome. You sure are doing good! I do have the one or other
semantic gripe - for instance the current usage of "module" instead of
"library" - but most of these have tickets already, so I decided to
concentrate on editing as long as I don't find anything major. (The only
real error I found up until now is that "guard" is not mentioned in the
tail call context list of section 1.3.5, but I already mentioned that in
the original message.)

> I think we can accommodate most of your suggestions.
> A couple of replies:
>
>> I was a bit suprised to see that the results of "when" and "unless" are
>> left completely unspecified.
>
> I prefer this semantics from a type-theoretic
> perspective, because the type remains the
> same whether the test passes or fails.  Also,
> `when' and `unless' are specifically used for
> side-effects, and this is consistent with other
> side-effecting operations.

Thinking about it, leaving this unspecified makes sense as one couldn't
use "when" and "unless" to return a value from a procedure anyway
without risking an unspecified return value (if the test evaluates to #f
or #t, respectively).

On the other hand, "begin" in an expression context also a sole
side-effect construct (otherwise, all expressions except the last in a
"begin" form would be useless) and still returns the last expression's
result. Given that "when" and "unless" are very similar, I find it to be
pretty intuitive if they have the same behavior. I'm undecided.

>> Maybe the example can be modified to include a case which calls another
>> case of the same procedure?
>
> I would still prefer to remove "case-lambda" from the
> report altogether, specifically because I think this use
> case is bad style, encouraging code duplication.

Maybe optional arguments should should be done in WG2 instead (together
with keyword arguments, maybe). However, this has been voted upon
already by the working group, so I haven't commented on the decision.

Reagards,
Denis

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports