[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Draft 3 Comments: Chapter 5
- To: Alex Shinn <alexshinn@x>
- Subject: Re: [Scheme-reports] Draft 3 Comments: Chapter 5
- From: Denis Washington <denisw@x>
- Date: Wed, 03 Aug 2011 09:54:04 +0200
- Cc: scheme-reports@x
- In-reply-to: <CAMMPzYP2Tq78uTHFq7pNr7pM71LGa33qU=PJsUDFb3g7iyiRZQ@mail.gmail.com>
- References: <4E36E9AF.firstname.lastname@example.org> <CAMMPzYP2Tq78uTHFq7pNr7pM71LGa33qU=PJsUDFb3g7iyiRZQ@mail.gmail.com>
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.
>> 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