[SPIKE] Parser per un semplice linguaggio

[fek]

Questa decisione spetta a Jocchan. Io vorrei che il linguaggio fosse leggibile come l'inglese e senza parentesi.

[cdimauro]

Perfettamente d'accordo. Vediamo cosa dice Jocchan prima di iniziare.

Io intanto mi studio ANTLR...

[Jocchan]

Io sono assolutamente per gli spazi come unico tipo di separatori, senza virgole nè parentesi (al limite solo un ";" al termine dei comandi, ma se possibile meglio non avere nemmeno quello).
Giusto per capirci, ecco un esempio:

show bg Ice
show character 1 Josh 325 248
show character 2 Kathy 525 248
move character 1 450 248 3
dialogue Josh  \"Ciao, hai impegni stasera?\"
anim character 2 37
dialogue Kathy \"Anvedi questo...\"
flash screen #FFFFFF 10
start battle Josh Kathy

P.S.: Per l'esempio ho usato i comandi che avevo elencato tempo addietro in questo post:

Originariamente inviato da Jocchan

Anche io propenderei per un linguaggio semplice e simile all'inglese, magari con la possibilità di svilupparlo man mano che andiamo avanti.
Insomma, se volessimo iniziare dalla parte dedicata alle cutscene, potremmo partire dall'introduzione di comandi come:

- wait (xx) <--- inutile spiegarlo
- show bg (personaggio) <--- mostra lo sfondo del personaggio dato
- dialogue (nomepersonaggio) (testo) <--- mostra una finestra con dei dialoghi in basso ed una gif "nomepersonaggio.gif" per l'intestazione della finestra
- show character (codice) (nomepersonaggio) (xx, yy) <--- mostra un pg alle coordinate date dandogli un codice identificativo
- move character (codice) (coord.destinazione) (velocità) <--- semplice traslazione fino alle coordinate date, con velocità settabile
- anim character (codice) (xx) <--- mostra l'animazione xx per il personaggio specificato
- delete character (codice) <--- elimina il pg
- show picture (codice) (xx, yy) (trasparenza%) (dimensioni) <--- idem, ma per una png statica con una % variabile di trasparenza
- move picture (codice) (coord.destinazione) (velocità) (trasparenza%) (dimensioni) <--- per spostare e trasformare la png in questione
- delete picture (codice) <--- elimina la png
- show text (coordinate) (font) (testo) <--- mostra del testo generico, con font variabile, allineato a sinistra e partendo dalle coordinate date
- flash screen (colore) (durata) <--- non credo ci sia bisogno di spiegarlo
- shake screen (potenza) (durata) <--- idem

Già con questi comandi, da implementare poco alla volta, si potrebbero creare praticamente TUTTE le cutscene del gioco
Per i comandi relativi al gioco vero e proprio devo valutare bene cosa serve, magari con un pò di consulenza tecnica


Vabbè le cutscene potremmo anche girarle con l'engine di The Movies...

[cdimauro]

OK. Unica cosa, eviterei \" per indicare l'inizio e la fine di una stringa: lascerei soltanto '"', che è più "naturale / intuitivo".

P.S. ANTLR è una gran figata.

[Jocchan]

In realtà avevo inserito \" perchè apparissero delle virgolette nel testo, considerando già gli spazi come separatori (il riconoscimento sarebbe iniziato subito dopo il primo parametro, e sarebbe terminato con il ritorno a capo)...
Ora, riflettendoci bene, le virgolette sono più propenso ad escluderle dal testo a video.
Magari per il parsing della stringa basta un " prima ed un " dopo, cosa che aumenta la leggibilità dello script

[71104]

Jocchan, è proprio necessario che i nomi dei comandi debbano contenere spazi? così le parti del nome successive alla prima si confondono coi parametri...
inoltre per favore quando hai pronta una lista di comandi anche provvisoria scrivila qui

[71104]

ho un'idea: siccome le istruzioni che abbiamo definito possono contenere come parametri solamente numeri e stringhe, per evitare confusioni tra parametri e parti del nome del comando basta correggere alcune cose nel tuo script di prova: i nomi dei personaggi (Josh e Kathy) mettili tra virgolette doppie; inoltre toglici il backslash dietro le virgolette

[Jocchan]

Originariamente inviato da 71104

ho un'idea: siccome le istruzioni che abbiamo definito possono contenere come parametri solamente numeri e stringhe, per evitare confusioni tra parametri e parti del nome del comando basta correggere alcune cose nel tuo script di prova: i nomi dei personaggi (Josh e Kathy) mettili tra virgolette doppie; inoltre toglici il backslash dietro le virgolette

Credo sia la cosa migliore, tanto gli unici parametri di tipo stringa dovrebbero essere appunto i nomi ed il contenuto dei dialoghi.
Vedrò di stilare una lista, nel frattempo potete prendere per buona quella vecchia (solo con il ritocco delle virgolette per le stringhe)

[fek]

Con Jocchan si pensava per i dialoghi a comandi di questa forma:

Josh says fast
  Hello, how are you?
  Everything's fine?
end

Io preferirei non vedere parentesi, virgolette, ma comandi semplicissimi come questo.

[cionci]

fek...messo in quel modo è molto facile e veloce da implementare...

Che ne dite di mettere ogni parametro in una nuova riga ?

Per i comandi con parametri variabili si legge fino a 'end'...

Una cosa di questo tipo:

wait 
  3000

show background 
   personaggio

Josh says
  fast
  Hello, how are you?
  Everything's fine?
end

show
  0001
  Josh

move character 
  0001
  328 
  100
  1

e così via...

Semplificherebbe molto il matching dei comandi ed il parsing delle stringhe...

[71104]

Originariamente inviato da fek

Io preferirei non vedere parentesi, virgolette, ma comandi semplicissimi come questo.

questo temo sia impossibile proprio perché appunto come dicevo prima i vari pezzi di un comando si confondono con i parametri non inclusi tra virgolette... almeno le virgolette per racchiudere le stringhe ci vogliono per forza imho... poi se avete altre soluzioni ottimo, purché la sintassi sia ben definita ed inequivocabile.

ma senti, il parser lo devo committare nel repository? oppure tengo solo la mia copia locale e ve lo incollo in un post del forum quando è finito?

[cionci]

Originariamente inviato da 71104

almeno le virgolette per racchiudere le stringhe ci vogliono per forza imho...

Non ci vogliono per forza se si mette ogni parametro di un comando una riga diversa...

[Jocchan]

Originariamente inviato da 71104

ma senti, il parser lo devo committare nel repository? oppure tengo solo la mia copia locale e ve lo incollo in un post del forum quando è finito?

Direi la seconda, per lo meno finchè non avremo una sintassi vera e propria.
L'idea di separare i vari parametri nelle varie righe mi sembra buona, però ho paura che si perda in leggibilità, quindi per ora eviterei questa soluzione.
Stavo riflettendo piuttosto sul fatto che non credo ci possano essere problemi con i comandi costituiti da due parole: la seconda infatti può essere sempre considerata come un parametro della prima.
Mi spiego meglio:

- move character
- move picture

Character e picture possono essere considerati come dei parametri per il comando "move". Idem per "show", "delete" e "anim" (per il quale il parametro picture non ha molto senso, ma va bene lo stesso con character).
Io sarei molto più orientato per dei comandi su una sola linea, insomma, credo sia più sintetico e più comodo da leggere e da scrivere.

[71104]

Originariamente inviato da cionci

Non ci vogliono per forza se si mette ogni parametro di un comando una riga diversa...

hum, ok, basta che ci mettiamo d'accordo...
poi ho scoperto una classe Java che ci aiuta moltissimo nel parsing, presente sia in Java 1.4.2 che nell'1.5: StreamTokenizer, che serve a dividere in tokens un InputStream e a leggerlo token per token; con questa classe e con una sintassi così semplice diventa tutto uno scherzo

fek, va bene se il progetto lo committo nel repository in una nuova directory con questo percorso

extras/Spikes/71104/CommandParser

?

[fek]

Originariamente inviato da 71104

hum, ok, basta che ci mettiamo d'accordo...
poi ho scoperto una classe Java che ci aiuta moltissimo nel parsing, presente sia in Java 1.4.2 che nell'1.5: StreamTokenizer, che serve a dividere in tokens un InputStream e a leggerlo token per token; con questa classe e con una sintassi così semplice diventa tutto uno scherzo

fek, va bene se il progetto lo committo nel repository in una nuova directory con questo percorso

extras/Spikes/71104/CommandParser

?

Si' perfetto

[cdimauro]

Originariamente inviato da fek

Con Jocchan si pensava per i dialoghi a comandi di questa forma:

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:

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:

Josh says fast "
  Hello, how are you?
  Everything's fine?"

Oppure:

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.

[cdimauro]

Originariamente inviato da Jocchan

Direi la seconda, per lo meno finchè non avremo una sintassi vera e propria.
L'idea di separare i vari parametri nelle varie righe mi sembra buona, però ho paura che si perda in leggibilità, quindi per ora eviterei questa soluzione.

Idem.

Stavo riflettendo piuttosto sul fatto che non credo ci possano essere problemi con i comandi costituiti da due parole: la seconda infatti può essere sempre considerata come un parametro della prima.
Mi spiego meglio:

- move character
- move picture

Character e picture possono essere considerati come dei parametri per il comando "move". Idem per "show", "delete" e "anim" (per il quale il parametro picture non ha molto senso, ma va bene lo stesso con character).

Non sono mica dei parametri: move character e move picture sono due comandi diversi.

Non farti problemi nel presentare "comandi" che abbiano più di una parola: non è questo che rende difficoltoso il parsing del testo.

move character at 320 240

Non è niente di eccezionale.

Io sarei molto più orientato per dei comandi su una sola linea, insomma, credo sia più sintetico e più comodo da leggere e da scrivere.

E anche da implementare.

Resta da definire se il case è significativo. Per il momento, per semplificare il parsing, proporrei di sì. Poi vediamo se è possibile rendere il parser case insensitive, che è sicuramente più "umano".
Per il parser "scritto a mano" è un problema di semplice soluzione, ma per un parser con ANTLR non è banale.

[cionci]

Originariamente inviato da cdimauro

E anche da implementare.

Non con il parser scritto a mano...

[fek]

Originariamente inviato da cdimauro

Per quanto detto, per adesso proporrei qualcosa del genere:

Josh says fast "
  Hello, how are you?
  Everything's fine?"

Oppure:

Josh says fast
"  Hello, how are you?
  Everything's fine?"

Proprio non mi piace l'idea di usare le virgolette. Secondo me se il linguaggio si mantiene molto semplice e' possibile farne a meno. C'e' da studiarci un po'. Il token \n in questo caso definirebbe, dopo il comando says, quando inizia la stringa, ed un 'end' a inizio riga definirebbe la fine. Mi sembra che Python abbia qualcosa di analogo.

Trattandosi di spike e non di task, magari per il momento direi di lasciare un certo margine di flessibilità nel linguaggio da riconoscere.

Certo, possiamo mantenere lo Spike complicato e flessibile per analizzare piu' problematiche possibile.

[^TiGeRShArK^]

Originariamente inviato da 71104

hum, ok, basta che ci mettiamo d'accordo...
poi ho scoperto una classe Java che ci aiuta moltissimo nel parsing, presente sia in Java 1.4.2 che nell'1.5: StreamTokenizer, che serve a dividere in tokens un InputStream e a leggerlo token per token; con questa classe e con una sintassi così semplice diventa tutto uno scherzo

fek, va bene se il progetto lo committo nel repository in una nuova directory con questo percorso

extras/Spikes/71104/CommandParser

?

stavi facendo il parser senza usare il tokenizer???