Am Mo., 31. Aug. 2020 um 15:14 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:

> I think I communicated poorly or we are talking past one another.

Or me, for that matter.

I think we can divide our misunderstanding into two separate parts.
One is, as I believe, fairly easy to resolve; the other is more
elaborate and much harder to explain.

(1) Whether cyclic literals are only allowed in explicit quotes.

(2) Whether (let-syntax ((q (syntax-rules () ((_ x) 'x)))) (q #=0(1 .
#0#))) is an error or not.

Ad (1). This is the easy one, I think: The standard only disallows
cycles in non-literals and does not mention quote in this context.
Some kinds of literals (the constants) do not have to be quoted. Thus,
I conclude, literal cycles do not necessarily appear in quoted form in
valid R7RS programs. For example, the vector literal #0=#(1 . #0#) is
a valid expression (a literal).

(This is already enough to infer that syntax-rules macros that
reliably dissect valid expressions are impossible in R7RS.)

Ad (2). This is harder, so I will try to do my best to explain my
reasoning. Before macro expansion (and not taking account lexical
contexts), a program (or library) is just a Scheme datum (or, rather,
represented by one) or a list of datums. The components of that data
are again data. When you claim that the language "except in literals"
talks about this lexical structure of the program and does not take
the expansion (and lexical contexts), "the resulting AST", into
account, you seem to implicitly claim that one can single out
particular datums in this lexical structure being literals or not.

My claim is that this is nonsensical (in the logical sense): Given the
following program fragment (under the assumption that we have imported
the standard identifiers)

    (foo (quote a))

does the datum (quote a) represent a literal or not? Obviously, we
cannot answer the question before macro expansion because foo may be a
macro, rebinding quote.

This does necessarily have to involve quote. Given

    (bar #(42))

does the vector datum #(42) represent a literal or not? Again, we
cannot tell before macro expansion.

I conclude that whether a lexical datum in a program is a literal or
not is a nonsensical question.

But even if talking just about the lexical structure made sense here,
if we read section 7.1 in this way, we would conclude that <macro
uses> wouldn't be allowed to contain literals, so

(let-syntax ((id (syntax-rules () ((id x) x))))
  (id (quote #0=(1 . #0#))))

would be an error as well, which we certainly do not want because this
would also disallow the definition of the standard derived expression
types in terms of macros.

If one takes a closer look at the formal language in 7.1, it becomes
even clearer that lexical context (and macro expansion) has to be
taken into account (vs. just a literal interpretation as Scheme
datums): One production rule for an <expression> is <procedure call>.
A <procedure call>, however, looks lexically exactly as a <macro use>.
To distinguish the two, one needs the lexical context, which is only
available after macro expansion.

I have a final argument against your interpretation. Even it were
true, it could have no practical consequences. Assume an
implementation wanted to enforce your rule. For that, to detect which
vector datums end up as vector literals, it would have to do a
complete expansion of the program anyway.

> If you wanted to allow more liberal use of such structures in a future standard,
> you would need to provide a specification.  It seems you want to define this to
> be any structure which eventually gets quoted in the AST, but I'm not sure that's
> good for a standard.  The problem is it runs into too many implementation details
> of both the macro expander and the macro implementation.  Thus you would
> need to add some specification of what the expander is required to support, and
> any macros defined in the standard or future SRFIs would need to specify
> whether they are required to support cyclic arguments.  Otherwise everything
> becomes (Scheme and macro) implementation-defined.

I am not sure I can follow you here completely. First of all, it is
not about what "eventually gets quoted in the AST", but what
"eventually is a literal in the AST". We don't necessarily need the
quote. It is enough to argue with vector datums and literals.

Next, I don't see what the macro expander has to do with the problem.
The macro expander is concerned about macro uses, and each macro use
is of the form

(<keyword> <datum> ...)

We note that this is a finite list, so if the expander happens to
stumble upon a syntax object of the form #0=(foo bar #0#) with foo
being whatever keyword, it is already an error (by whatever reading of
the R7RS).

The transformer associated with the <keyword> can, of course, dissect
each <datum> to the extent possible by the macro system (e.g.
syntax-rules, syntax-case, or er-macro-transformer, of which,
incidentally, only the last one is able to reliably detect cycles in
<datum>s), but there is no need to specify anything special. Of
course, a macro can loop when recursively scanning a cyclic <datum>,
but so can macros without cyclic <datum>s. Actually, the former is
much more harmless because it is easier to detect by the macro
expander.

I don't want to change a single word in the R7RS. Everything that you
wrote in the report makes perfect sense. :)

Marc