Marc, do you agree with the rewriting proposal of Peter below? I think
he found the correct wording for solving one of the objection you
raised.

Le Tue, 1 Sep 2026 08:29:17 -0400,
Peter McGoron <xxxxxx@mcgoron.com> a écrit :

[snip]

>  > It implies that part of the specification is to be rewritten. I
>  > have
> to check. It will take time...
>
> I think addressing Marc's point is simple.
>
> The spec uses "parentheses" and "spaces" to mean "lists" and
> "separate elements of a list." These are pretty commonly interchanged
> when talking informally, but are confusing when we talk about
> parsing. By replacing these you should be able to fix the problem.
>
> My suggestions:
>
> Your text:
>
>  > The arguments are either a single expression or a subexpression in
>  >
> parentheses. When it is a subexpression in parentheses, the arguments
> of the call are separated by spaces.
>
> This should read
>
>  > The arguments are either a single expression or a list
>  > subexpression.
> When it is a list subexpression, the arguments of the call are the
> elements of the list.
>
> Your text:
>
>  > Subexpressions are expressions enclosed in parentheses.
>
> Should be:
>
>  > Subexpressions are list data (i.e. lexically, they are enclosed in
>  >
> parentheses).
>
> Your text in the description of "call":
>
>  > Space separated arguments.
>
> Should be removed.
>
> Your text:
>
>  > Expressions can have subexpressions in parentheses.
>
> Should be:
>
>  > Expressions can have subexpressions, which are list data (i.e.
> lexically, they are enclosed in parentheses).
>
> Your text:
>
>  > When argument of a call, spaces are interpreted as separating
>  > arguments.
>
> Should be:
>
>  > Each element of the list is interpreted as an argument to the
>  > call.
>
> _______________________________
>
>  > I was thinking I used R6RS macro facilities, but Marc tells I
>  > don't,
> so I have to check. It will take time...
>
> If the above changes are made, I think this point is addressed too.