Quote:
|
Originariamente inviato da fek
Con Jocchan si pensava per i dialoghi a comandi di questa forma:
Codice:
Josh says fast
Hello, how are you?
Everything's fine?
end
Io preferirei non vedere parentesi, virgolette, ma comandi semplicissimi come questo.
|
Preferisco anch'io questo tipo di sintassi: più ci si avvicina ai linguaggi "umani", meglio è.
Però con con l'esempio che hai proposto sorgono problemi con i generatori di parser "canonici".
Ad esempio, dopo il token "fast" il testo è da prendere così com'è, tenendo conto soltanto dell' "end" + new line per indicare al fine di questo tipo di parsing.
Con yacc non sarebbe tanto problematica la cosa, perché il lex è un "modulo" a se stante, per cui è facile scrivere degli analizzatori lessicali che cambino anche radicalmente il loro comportamento in base al contesto attuale.
Ad esempio, io ho sempre scritto i lex "a mano", passando i token al parser yacc, e potendo in qualsiasi momento mostrare o nascondere dei token "al volo".
Ad esempio in linguaggi come il pascal, dov'è possibile definire roba come questa:
Codice:
procedure Pippo; cdecl; external;
begin
end;
i token cdecl ed external si possono attivare dopo la definizione di Pippo e disattivare subito prima dell'inizio della procedura (prima del begin).
Con ANTLR è un po' diverso, perché il lexer lo puoi generare direttamente nel file della grammatica del parser. Anzi, è esattamente quello che si fa normalmente: non ho ancora visto esempi di lexer "scritti a mano" e utilizzati dalla classe che del parser (darò un'altra occhiata alla documentazione e ai forum).
Comunque in generale linguaggi "umani" comportano dei problemi quando si "mischiano" quelli che sono dei token da riconoscere dai "dati", questo è poco ma sicuro.
Sul fatto di mettere Josh e Kathy come stringa, non sono molto d'accordo: se i personaggi sono "predefiniti", si possono includere nell'elenco dei token in modo da evitare l'uso di '"' per rappresentarli negli script. Inoltre in questo modo deleghiamo già al parser il compito di controllare se quello specificato è un character valido oppure no; altrimenti dovremmo farlo noi, a livello di codice, andando a controllare COMUNQUE se il nome immesso fa parte di una lista: cioé la stessa cosa che farebbe il parser normalmente.
Per quanto detto, per adesso proporrei qualcosa del genere:
Codice:
Josh says fast "
Hello, how are you?
Everything's fine?"
Oppure:
Codice:
Josh says fast
" Hello, how are you?
Everything's fine?"
Entrambe possono essere implementate senza troppi problemi (normalmente le stringhe non vanno a capo e il newline indica la fine di un comando. In questo caso il newline non dev'essere processato finché la stringa non viene chiusa; è necessario di definire un altro tipo di stringa rispetto agli altri casi).
Quanto ad ANTLR, è molto potente anche perché, a differenza di tool come YACC & derivati (che generano un automa a stati, che necessita di un certo tempo), genera dei parser di tipo recursive descendant: quindi MOLTO veloci nell'eseguire il parsing. Non è il nostro caso, ma è comunque utile saperlo (a me interessa moltissimo

).
Trattandosi di spike e non di task, magari per il momento direi di lasciare un certo margine di flessibilità nel linguaggio da riconoscere. Discutiamone un po', magari cercando di non mettere dei paletti preventivamente. Vediamo di realizzare qualcosa di funzionante, anche soltanto a livello embrionale, e di decidere poco alla volta cosa aggiungere.
Questo lo dico perché scrivere un parser per un linguaggio non è una cosa semplice, ma a volte lavorandoci saltano fuori delle problematiche derivante dal fatto che certe grammatiche sono difficili da implementare; è facile che magari aggiungendo un nuovo elemento al linguaggio sorgano dei conflitti.