[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Draft 3 Comments: Chapter 5

Am 03.08.2011 08:21, schrieb Alex Shinn:
> Hi Denis,
> Thanks again for the detailed comments.
> On Tue, Aug 2, 2011 at 3:00 AM, Denis Washington<denisw@x>  wrote:
>> 5.1. Programs
>> =============
>>   From what I can see, this is mostly R5RS (except for small adjustments
>> to mention modules) and inherits a certain lack of preciseness from it.
> This was very intentional - both the small deviation from R5RS and
> the "lack of preciseness," which is another way of saying "flexibility."
> The fact of the matter is that implementations differ greatly, implementors
> like adding and experimenting with their own features, and the purpose
> of the "small language" is to provide a minimum common ground on
> which implementations can agree and still share useful code.
> The "large language" and/or future standards can be used to
> nail down the semantics when and if we get on the same page.

Fair enough.

>> Specifically, it is not really said what the mentioned "top level" of a
>> program actually is (it is somewhat deducible from the context, but
>> "somewhat deducible" isn't quite enough for a standards document IMO). I
>> know I have pointed to R6RS more than enough in my last review message,
>> but its section 8 ("Top-level Programs") might be helpful here.
> This could possibly be disastrous for implementor uptake, since one
> of the most common complaints against R6RS was its handling of
> top-levels, and specifically its forbidding of REPLs.

Oh, I didn't realize that the R6RS semantics rule out REPLs; if that is 
the case, I agree that this wouldn't be a good idea. What I essentially 
meant, though, was to clarify that "top-level form" means "form not 
embedded into other forms", something that is obvious to a Schemer but 
not necessarily to everyone. (I'm thinking of students or other Scheme 
newcomers who want to detail their knowledge by reading the report.)

> [...]
>> Rather than saying that the transformer should be a syntax-rules form,
>> it might be preferable to say that it should be a macro transformer but
>> that syntax-rules is the only one defined in this report.
> Good point, we'll change this.
> [...]
>> The added paragraph regarding ambiguous definitions is very, very hard
>> to understand; the sentences are not particularly well digestible. But I
>> admit that it is very hard to explain. ;) A proposal:
> Yes, the source has a TODO to revisit that paragraph.  We may
> use your proposal, or try to come up with a simpler way to explain it.



Scheme-reports mailing list