Qual è il modo corretto di distinguere tra parole chiave e identificatori?

Question

Qual è il modo corretto di distinguere tra parole chiave e identificatori?

#1 da (5 voti)
#2 da (2 voti)
#3 da (1 voti)

5

Sono consapevole del fatto che la maggior parte delle lingue moderne utilizza parole riservate per impedire che parole come le parole chiave vengano utilizzate come identificatori.

Le parole riservate a parte, assumiamo un linguaggio che consenta l'uso di parole chiave come identificatori. (Ad esempio, in Ruby può essere usata una parola chiave come nome di un metodo). Durante la compilazione, come gestiresti questa ambiguità?

La fase di lexing non sembra una buona scelta perché dovrebbe prendere in considerazione i token che la circondano. Anche la fase di parsing non sembra una buona scelta dato che idealmente il parser potrebbe funzionare con token non ambigui .

Se dovessi progettarlo da solo, suppongo che il lexer produrrà un token ambiguo, quindi avrò un altro livello che considera il token ambiguo nel contesto dei token che lo circondano (ad esempio, il token ambiguo segue una def parola chiave? Quindi deve essere un identificatore.) Quindi, vorrei consegnare i token non ambigui al parser.

Nelle lingue che consentono l'uso di parole chiave come identificatori, qual è il modo standard in cui il compilatore può distinguerle?

language-design parsing lexer

posta jhewlett 24.07.2013 - 06:32

fonte

3 risposte

2

In .Net, ogni lingua ha un diverso insieme di parole chiave. Ad esempio, ciò significa che una libreria scritta in C # può utilizzare identificativi riservati in VB.NET. Pertanto, per utilizzare tale libreria da VB.NET, è necessario utilizzare le parole chiave come identificatori.

Ogni lingua usa una sintassi diversa per farlo:

in C #, aggiungi un @ :
```
@keyword
```
in VB.NET, lo si racchiude tra parentesi:
```
[keyword]
```
in F #, lo si racchiude in doppi apici:
```
''keyword''
```

risposta data 24.07.2013 - 10:36

fonte

1

Non penso che ci sia un modo standard.

A volte vedrai alcuni trucchi lexer che implementano regole come "puro è una parola chiave solo se il prossimo token è la parola chiave nativa".

Altre volte il grammatico può utilizzare il fatto che in alcune circostanze tutte o alcune parole chiave possono essere interpretate come identificatori senza introdurre l'ambiguità.

risposta data 24.07.2013 - 16:51

fonte

Leggi altre domande sui tag language-design parsing lexer

Quali sono i vantaggi / svantaggi dell'uso di oggetti come parametri per altri metodi di oggetti? È accettabile che le classi figlie "interrompano" la funzionalità della classe genitore?

score 5 · Accepted Answer

Se noti in Ruby, non puoi chiamare direttamente il metodo chiamato così, ad es. non puoi fare

begin()

Puoi fare

obj.begin()

Perché lì puoi avere la grammatica del tipo:

*Arguments* :
    "(" ")"

*MemberExpression* :
    *MemberExpression* "." *IdentifierName*

*CallExpression* :
    *MemberExpression* *Arguments*

(Regole non correlate all'esempio tralasciato per brevità)

per riconoscerlo. Richiede solo la separazione della regola Identificatore da IdentifierName :

*Identifier*:
    *IdentifierName* **but not reserved word**

*IdentifierName*:
    //Rules for identifier names here

Se hai un antipasto begin come in

begin()

Quindi hai già attivato una regola come

*Block*:
    "begin" *indent* *statement* *outdent* "end"

E Ruby non cerca di capire cosa intendi e sarà solo un blocco.

Ma per i nomi dei metodi in cui appare un ricevitore o un altro prefisso, è facile consentire le parole chiave nella grammatica e ad es. Javascript lo fa.

Esempi di grammatica tratti da ecma-262