> That pattern matcher has no idea what DO means, in much same way that the reader doesn't know what DO means. 'means' is in the domain of semantics. We talk a

> That pattern matcher has no idea what DO means, in much same way that the reader doesn't know what DO means. 'means' is in the domain of semantics. We talk about syntax: structure. But what we know at this stage: DO is the CL:DO macro. So we know the actual operator, not just the symbol. We also know that it is a macro. We also know that the macro has a macro lambda list (CLHS 3.4.4 describes the syntax of those). We can now check the macro form against the actual CL:DO macro lambda list structure. And so on... Thus we are now talking about the Lisp language, its operators and its structure requirements. That's the purpose of a language parser: it has to know which symbols/identifiers are actual elements of the language, which operators these actually are and retrieves the syntactic constraints/rules for those. In a language like Common Lisp (or similar dialects) this is 'difficult', since there are lexical bindings, compile-time side-effects and even lexical bindings to establish new syntax (macrolet). > The syntax notation like: ... is relying on read syntax; it has parentheses in it! It describes constraints on the structure (!) of valid Lisp forms. -> syntax! (do () () "foo") -> Ill-formed DO end test list (do () (t) "foo") -> no legal go tag (do ((a b c d)) (t)) -> illegal form for a DO varlist See that the warnings talk about the actual Lisp operators and their requirements? We've left the domain of s-expression syntax here and talk about Lisp syntax requirements. None of these things are caught by the READER. All of these are actual warnings from SBCL. > The init-form can be anything: a struct literal, vector, string, character. Yet, I don't see the rules for that in this grammar; they given elsewhere, and just assumed here. The rules are in the language standard. The non-terminal INIT-FORM is specified to be a FORM. Which then is defined elsewhere. > The init-form can be anything Actually it can't. It must be a form (see the CLHS syntax description for DO). Thus ((foo)) for example is not valid, since it is not a valid Common Lisp form. > From the perspective of any one S-expression, though, the bulk of the specification of its syntax is in the domain of the reader. This is tautologic. I was claiming that Lisp has structural constraints/rules on top (!) of s-expressions (and especially s-expressions as data) and gave the example of the Common Lisp standard, which describes these in an eBNF syntax.