In my proposed additional wording only "it is an error" terminology is used -- and there is no "unspecified" in the whole SRFI. The "is an error" wording gives the implementation the usual choice: 1) detect and report an error (via signaling mechanism or not); 2) provide non-portable extensions; 3) fail catastrophically. Your example (match procedure? ((~and thing (~? thing)) 'early-binding) (_ 'should-never-happen)) is, as specified, an erroneous program, and thus belongs to the same class as, say, (let (x . y) z). As I see it, erroneous programs have no scoping rules -- I don't think there is such thing as 'scope' for x or y in (let (x . y) z). So I understand why excluding a subclass of matching constructs from a class of all matching constructs with defined semantics may be considered unsatisfactory, but I had reasons for this decision, and I have tried to present them in one of the previous posts. My point about define-syntax in R6RS and R7RS bodies is to show an example of a specification that deals with scoping/use issues indirectly -- instead of just saying "the scope of this syntax keyword starts here and ends there, and it can be used anywhere in this sub-region here", there is a complex specification of the expansion process (R6RS), accompanied by a description of what must not happen while this process is ongoing; R7RS only has the latter part. I don't claim that the situations are "the same" in any sense of the phrase, only that "operational" descriptions have their place in Scheme proposals. By "operational" here I mean things like "the definition/use pattern must satisfy the constraint that such-and-such doesn't happen, otherwise it is an error". This is just an observation, not a critique of any approach to specify semantics -- all of them do their job. --Sergei -----Original Message----- From: Daphne Preston-Kendal Sent: Monday, October 20, 2025 2:47 PM To: Sergei Egorov Cc: xxxxxx@srfi.schemers.org Subject: Re: scope On 20 Oct 2025, at 19:08, Sergei Egorov <xxxxxx@acm.org> wrote: > The scope is not unspecified, it is specified operationally, by imposing constraints that should hold for a program to have a > defined semantics. Not a new thing for Scheme: this is the approach taken by R6RS/R7RS editors with respect to define-syntax in > bodies. This seems to be a rather deep misunderstanding. In my example, (match procedure? ((~and thing (~? thing)) 'early-binding) (_ 'should-never-happen)), your proposed spec language makes the binding of ‘thing’ in the evaluation of the expression in (~? thing) unspecified. If a binding is unspecified, the scoping rules are unspecified. (Worse than unspecified, because there is no obligation for an implementation to do one of the ‘obvious’ things when something is specified as UB. If it were merely unspecified, it would at least be safe.) There is no case in R6RS which is unspecified in this way. In R7RS small, there is no real comparable case, only that of syntactic use-before-definition within a body, which is unspecified, but use after definition, which this example lexically is, is perfectly well specified. (Though I note your ~and doesn’t guarantee left-to-right order nor by extension short circuiting.) The situation in the draft R7RS large is the same as in R6RS. Daphne
