Em qual processo ocorre o erro de sintaxe? (tokenização ou análise)

Estou tentando entender compilação e interpretação, passo a passo, descobrindo uma imagem total. Por isso, fiz uma pergunta ao ler http://www.cs.man.ac.uk/~pjj/farrell/comp3.html este artigo

Diz :

O próximo estágio do compilador é chamado de analisador. Esta parte do compilador possui um entendimento da gramática da linguagem. Ele é responsável por identificar erros de sintaxe e por traduzir um programa sem erros em estruturas de dados internas que podem ser interpretadas ou gravadas em outro idioma.

Mas não consegui descobrir como o tokenizer pode tokenizar adequadamente o fluxo especificado que possui o erro de sintaxe.

Ele deve ficar preso ou fornecer informações erradas ao analisador. Quero dizer, o tokenizing também não é um tipo de tradutor?

Então, como ele simplesmente supera as linhas lexicais de código corrompidas ao usar token.

Há um exemplo de token dentro do link acima no cabeçalho do Tokenizer .

Pelo que entendi, parece que a forma do token, se houver algo errado no token de código, também estará corrompido.

Poderia, por favor, esclarecer meu mal-entendido?

Um tokenizer é apenas uma otimização de analisador. É perfeitamente possível implementar um analisador sem um tokenizador.

Um tokenizador (ou lexer ou scanner) divide a entrada em uma lista de tokens. Algumas partes da string (comentários, espaço em branco) geralmente são ignoradas. Cada token possui um tipo (o significado dessa string no idioma) e um valor (a string que compõe o token). Por exemplo, o trecho de código-fonte PHP

$a + $b

pode ser representado pelos tokens

Variable('$a'),
Plus('+'),
Variable('$b')

O tokenizer não considera se um token é possível nesse contexto. Por exemplo, a entrada

$a $b + +

alegremente produziria o fluxo de token

Variable('$a'),
Variable('$b'),
Plus('+'),
Plus('+')

Quando o analisador consome esses tokens, ele notará que duas variáveis ​​não podem se seguir e nem dois operadores de infixo. (Observe que outros idiomas têm sintaxes diferentes, onde um fluxo de token pode ser legal, mas não no PHP).

Um analisador ainda pode falhar no estágio do tokenizer. Por exemplo, pode haver um caractere ilegal:

$a × ½ — 3

Um tokenizador PHP seria incapaz de corresponder essa entrada às suas regras e produziria um erro antes do início da análise principal.

Mais formalmente, os tokenizadores são usados ​​quando cada token pode ser descrito como um idioma comum . Os tokens podem ser correspondidos com extrema eficiência, possivelmente implementados como um DFA. Por outro lado, a gramática principal geralmente é livre de contexto e requer um algoritmo de análise mais complicado e com menos desempenho, como o LALR.

Você normalmente espera que a maioria dos erros de sintaxe venha do analisador, não do lexer.

O lexer geraria um erro se (e principalmente somente se) houver algo na entrada que não possa ser tokenizado. Em muitos idiomas, no entanto, quase qualquer sequência de caracteres pode ser transformada em algum tipo de tokens; portanto, os erros aqui são bastante incomuns.

O analisador gerará um erro se a entrada contiver tokens válidos, mas esses tokens não estiverem organizados para formar declarações / expressões válidas no idioma de destino. Isso é muito mais comum como regra.

O tokenizador apenas divide o fluxo de caracteres em tokens. No tokenizer POV, isso é completamente válido:

1 * * 1

e traduz para algo como: ["1", MULTIPLY, MULTIPLY, "1"] Apenas o analisador pode rejeitar essas expressões - ele sabe que o operador multiplicador não pode seguir outro operador multiplicador. Por exemplo, em JavaScript, isso produz:

Uncaught SyntaxError: Unexpected token *(…)

Existem erros que podem ser detectados pelo tokenizer. Por exemplo literais inacabadas string: "abcou números inválidos: 0x0abcdefg. Eles ainda podem ser relatados como erros de sintaxe:

Uncaught SyntaxError: Unexpected token ILLEGAL

Observe, no entanto, o token não foi reconhecido e é relatado como ILLEGAL.