Quale dovrebbe essere il tipo di dati dei token che un lexer restituisce al suo parser?

Come detto nel titolo, quale tipo di dati dovrebbe restituire / dare al parser un lexer? Nel leggere l' articolo di analisi lessicale di Wikipedia, si afferma che:

Nell'informatica, l'analisi lessicale è il processo di conversione di una sequenza di caratteri (come un programma per computer o una pagina Web) in una sequenza di token ( stringhe con un "significato" identificato).

Tuttavia, in completa contraddizione con la precedente dichiarazione, quando è stata data risposta a un'altra domanda che ho posto su un altro sito ( Revisione del codice se sei curioso), la persona che ha risposto ha dichiarato che:

Il lexer di solito legge la stringa e la converte in un flusso ... di lexemi. I lessemi devono solo essere un flusso di numeri .

e ha dato questo aspetto:

nl_output => 256
output    => 257
<string>  => 258

Più avanti nell'articolo Ha menzionato Flexun lexer già esistente e ha detto che scrivere "regole" con esso sarebbe più semplice che scrivere un lexer a mano. Ha proceduto a darmi questo esempio:

Space              [ \r\n\t]
QuotedString       "[^"]*"
%%
nl_output          {return 256;}
output             {return 257;}
{QuotedString}     {return 258;}
{Space}            {/* Ignore */}
.                  {error("Unmatched character");}
%%

Per approfondire la mia conoscenza e ottenere maggiori informazioni, ho letto l'articolo di Wikipedia su Flex . l'articolo Flex mostrava che era possibile definire un insieme di regole di sintassi, con token, nel modo seguente:

digit         [0-9]
letter        [a-zA-Z]

%%
"+"                  { return PLUS;       }
"-"                  { return MINUS;      }
"*"                  { return TIMES;      }
"/"                  { return SLASH;      }
"("                  { return LPAREN;     }
")"                  { return RPAREN;     }
";"                  { return SEMICOLON;  }
","                  { return COMMA;      }
"."                  { return PERIOD;     }
":="                 { return BECOMES;    }
"="                  { return EQL;        }
"<>"                 { return NEQ;        }
"<"                  { return LSS;        }
">"                  { return GTR;        }
"<="                 { return LEQ;        }
">="                 { return GEQ;        }
"begin"              { return BEGINSYM;   }
"call"               { return CALLSYM;    }
"const"              { return CONSTSYM;   }
"do"                 { return DOSYM;      }
"end"                { return ENDSYM;     }
"if"                 { return IFSYM;      }
"odd"                { return ODDSYM;     }
"procedure"          { return PROCSYM;    }
"then"               { return THENSYM;    }
"var"                { return VARSYM;     }
"while"              { return WHILESYM;   }

Mi sembra che il lexer Flex stia restituendo stringhe di parole chiave \ token. Ma potrebbe restituire costanti uguali a determinati numeri.

Se il lexer avesse restituito dei numeri, come avrebbe letto i letterali delle stringhe? la restituzione di un numero va bene per singole parole chiave, ma come gestiresti una stringa? Il lexer non dovrebbe convertire la stringa in numeri binari e quindi il parser convertirà i numeri in una stringa. Sembra molto più logico (e più semplice) per il lexer restituire stringhe e quindi consentire al parser di convertire qualsiasi valore letterale in numeri reali.

O il lexer potrebbe restituire entrambi? Ho provato a scrivere un semplice lexer in c ++, che ti consente di avere un solo tipo di ritorno per le tue funzioni. Mi porta così a porre la mia domanda.

Per condensare la mia domanda in un paragrafo: quando si scrive un lexer e si assume che possa restituire un solo tipo di dati (stringhe o numeri), quale sarebbe la scelta più logica?

Generalmente, se stai elaborando una lingua attraverso il lessing e l'analisi, hai una definizione dei tuoi token lessicali, ad esempio:

NUMBER ::= [0-9]+
ID     ::= [a-Z]+, except for keywords
IF     ::= 'if'
LPAREN ::= '('
RPAREN ::= ')'
COMMA  ::= ','
LBRACE ::= '{'
RBRACE ::= '}'
SEMICOLON ::= ';'
...

e hai una grammatica per il parser:

STATEMENT ::= IF LPAREN EXPR RPAREN STATEMENT
            | LBRACE STATEMENT BRACE
            | EXPR SEMICOLON
EXPR      ::= ID
            | NUMBER
            | ID LPAREN EXPRS RPAREN
...

Il tuo lexer prende il flusso di input e produce un flusso di token. Il flusso di token viene utilizzato dal parser per produrre un albero di analisi. In alcuni casi, è sufficiente conoscere il tipo di token (ad esempio, LPAREN, RBRACE, FOR), ma in alcuni casi è necessario il valore effettivo associato al token. Ad esempio, quando incontri un token ID, ti serviranno i caratteri effettivi che compongono l'ID in un secondo momento quando stai cercando di capire a quale identificatore stai cercando di fare riferimento.

Quindi, in genere hai qualcosa di più o di meno come questo:

enum TokenType {
  NUMBER, ID, IF, LPAREN, RPAREN, ...;
}

class Token {
  TokenType type;
  String value;
}

Pertanto, quando il lexer restituisce un token, sai di che tipo è (di cui hai bisogno per l'analisi) e la sequenza di caratteri da cui è stata generata (di cui avrai bisogno in seguito per interpretare stringhe e valori numerici numerici, identificatori, eccetera.). Potrebbe sembrare che stai restituendo due valori, poiché stai restituendo un tipo aggregato molto semplice, ma hai davvero bisogno di entrambe le parti. Dopotutto, vorresti trattare i seguenti programmi in modo diverso:

if (2 > 0) {
  print("2 > 0");
}

if (0 > 2) {
  print("0 > 2");
}

Questi producono la stessa sequenza di tipi di token : IF, LPAREN, NUMBER, GREATER_THAN, NUMBER, RPAREN, LBRACE, ID, LPAREN, STRING, RPAREN, SEMICOLON, RBRACE. Questo significa che analizzano anche lo stesso. Ma quando stai effettivamente facendo qualcosa con l'albero di analisi, ti preoccuperai che il valore del primo numero sia '2' (o '0') e che il valore del secondo numero sia '0' (o '2 ') e che il valore della stringa è' 2> 0 '(o' 0> 2 ').

Come detto nel titolo, quale tipo di dati dovrebbe restituire / dare al parser un lexer?

"Token", ovviamente. Un lexer produce un flusso di token, quindi dovrebbe restituire un flusso di token .

Ha menzionato Flex, un lexer già esistente, e ha detto che scrivere "regole" con esso sarebbe più semplice che scrivere un lexer a mano.

I lexer generati automaticamente hanno il vantaggio di poterli generare rapidamente, il che è particolarmente utile se pensi che la tua grammatica lessicale cambierà molto. Hanno lo svantaggio che spesso non si ottiene molta flessibilità nelle scelte di implementazione.

Detto questo, a chi importa se è "più semplice"? Scrivere il lexer di solito non è la parte difficile!

Quando si scrive un lexer e si assume che possa restituire un solo tipo di dati (stringhe o numeri), quale sarebbe la scelta più logica?

Né. Un lexer in genere ha un'operazione "successiva" che restituisce un token, quindi dovrebbe restituire un token . Un token non è una stringa o un numero. È un segno.

L'ultimo lexer che ho scritto è stato un lexer a "piena fedeltà", il che significa che ha restituito un token che tracciava la posizione di tutti gli spazi bianchi e i commenti - che chiamiamo "curiosità" - nel programma, nonché il token. Nel mio lexer un token era definito come:

• Una serie di curiosità principali
• Un tipo di token
• Una larghezza token in caratteri
• Una serie di curiosità finali

La curiosità è stata definita come:

• Un tipo di curiosità: spazi bianchi, newline, commenti e così via
• Una larghezza di curiosità nei personaggi

Quindi se avessimo qualcosa del genere

    foo + /* comment */
/* another comment */ bar;

che sarebbe lex quattro gettoni con tipi di token Identifier, Plus, Identifier, Semicolon, e larghezze 3, 1, 3, 1. Il primo identificatore è leader curiosità costituito da Whitespaceuna larghezza di 4 e finali curiosità Whitespacecon larghezza di 1. L'Plus ha curiosità leader e trivia finale composta da uno spazio bianco, un commento e una nuova riga. L'identificatore finale ha una curiosità principale di un commento e uno spazio e così via.

Con questo schema ogni personaggio nel file viene preso in considerazione nell'output del lexer, che è una proprietà utile da avere per cose come la colorazione della sintassi.

Ovviamente, se non hai bisogno delle curiosità, puoi semplicemente fare un token due cose: il tipo e la larghezza.

Potresti notare che il token e le curiosità contengono solo le loro larghezze, non la loro posizione assoluta nel codice sorgente. È deliberato. Tale schema presenta vantaggi:

• È compatto in formato memoria e filo
• Consente il re-lessing sulle modifiche; questo è utile se il lexer è in esecuzione all'interno di un IDE. Cioè, se rilevi una modifica in un token, esegui il backup del lexer su un paio di token prima della modifica e ricomincia a eseguire il lex fino a quando non sei sincronizzato con il flusso di token precedente. Quando si digita un carattere, la posizione di ogni token dopo quel carattere cambia, ma di solito solo uno o due token cambiano in larghezza, quindi è possibile riutilizzare tutto quello stato.
• L'offset esatto dei caratteri di ogni token può essere facilmente derivato ripetendo il flusso di token e tenendo traccia dell'offset corrente. Una volta ottenuti gli offset di caratteri esatti, è facile estrarre il testo quando necessario.

Se non ti interessa nessuno di questi scenari, un token potrebbe essere rappresentato come un tipo e un offset, piuttosto che un tipo e una larghezza.

Ma la chiave da asporto qui è: la programmazione è l'arte di fare astrazioni utili . Stai manipolando i token, quindi fai un'astrazione utile sui token e poi puoi scegliere tu stesso quali dettagli di implementazione sono alla base.

Generalmente, si restituisce una piccola struttura che ha un numero che indica il token (o il valore enum per facilità d'uso) e un valore opzionale (stringa o eventualmente valore generico / modello). Un altro approccio sarebbe quello di restituire un tipo derivato per gli elementi che devono contenere dati extra. Entrambi sono leggermente disgustosi, ma abbastanza bene soluzioni a un problema pratico.