Normalizzazione EOL: Sia "\r" che "\n" dovrebbero produrre EOL nativo

[tajmone]

Secondo me Polygen dovrebbe gestire in maniera diversa le sequenze di fine riga (EOL). Allo stato attuale, sta all'utente specificare se usare LF o CRLF tramite le sequenze escape \n e \r.

Oggigiorno, il modo in cui vengono usate le EOL è cambiato dall'epoca in cui Polygen fu creato. Oggi l'aspettativa è che \n produca la sequenza EOL nativa del sistema operativo (CRLF su Windows, LF negli altri OS).

Allo stato attuale, le EOL creano problemi quando si reindirizza l'output di Polygen ad altre applicazioni. Per esempio, pandoc si aspetta un EOL nativo, e in Windows ignorerà le sequenze LF o CR; lo stesso vale per la maggior parte delle applicazioni moderne.

Il problema è che, attualmente, chi scrive grammatiche per Linux o Mac tende a usare \n per le nuove righe, mentre chi le scrive per Windows tende a usare \r\n — in realtà, nella maggior parte dei casi viene usato solo \n, ma in alcuni contesti di Windows è necessario usare \r\n per preservare la nuova riga (p.es: markdown e altri formati di testo).

La soluzione ideale, a mio avviso sarebbe questa:

• \n dovrebbe essere interpretata da Polygen come EOL nativa.
• \r dovrebbe essere deprecata, ma preservata per ragioni di retrocompatibilità, e trattata come se fosse \n.
• Occorrenze di \r\n dovrebbero essere trattate come un singolo \n (per evitare che una interruzione di riga venga interpretata come doppia)
• Una nuova opzione da riga di comando dovrebbe consentire l'override della EOL nativa: -eol lf per imporre \n = LF (possibili valori per -eol: lf|crlf|cr).

Quest'ultima opzione si rivelerebbe fondamentale nella creazione di script Shell o Batch, dove è necessario usare \n e \r\n rispettivamente, a prescindere dall'OS su cui si sta lavorando.

In teoria, oggi CR non viene più usato come carattere EOL, veniva usato solo dai primi OS del Machintosh, ma vale comunque la pena di offrire la possibilità di utilizzarlo tramite opzioni riga di comando.

Praticamente, Polygen dovrebbe normalizzare i caratteri EOL nel suo output — convertendo tutte le occorrenze di \n e \r nel carattere EOL nativo, o in quello specificato tramite opzioni, e normalizzare anche eventuali caratteri EOL introdotti tramite Ascii escapes (\010 e \013).

Ho altresì notato che il comportamento di Polygen riguardo alle EOL è diverso quando si usa l'opzione -o DEST: in questo caso il carattere EOL è quello nativo dell'OS.

Che ne pensi?

[alvisespano]

Ciao Tristano, scusa ma ultimamente non ho tanto tempo e rispondo ogni tanto. Ci ho riflettuto un po' e sai cosa sarebbe la soluzione più figa? Rendere l'EOL un token speciale del post-processore del polygen. Come forse già sai, il Polygen ha sia un pre-processore che un post-processore. La pipeline è: INPUT -> parsing -> pre-processing -> checking -> generation -> post-processing -> OUTPUT. Tale post-processore si occupa di renderizzare una stringa a partire da ciò che ha generato lo stadio di generazione. L'output del generatore non è una stringa, è una sequenza di token che possono essere: simboli terminali o token speciali, ovvero il token di concatenazione (^), il token di epsilon-produzione (_) e il token di capitalizzazione (\). Il motivo per cui esiste questo meccanismo è per rendere davvero potente la manipolazione a basso livello dell'output: i token speciali sono generabili dal generatore alla stregua di terminali qualsiasi, con tutti i benefici del caso. Se gestissi EOL come un command line argumet, dovrei sostituire tutte le occorrenze di '\n' o '\r' in qualcos'altro nell'output finale, ma questo è un po' sporco: nel senso che è un replace traballante, un hack che introduce casi di invalidità e comportamenti arbitrari, non una soluzione profonda al problema. Se invece introduciamo un nuovo special token, lo chiamiamo \n ad esempio (o un nome migliore, ci pensiamo meglio), e questo token non è il terminale "\n" scritto come stringa tra quote, ma un token speciale appositamente riconosciuto -- allo stesso modo di ^ o \ o _ -- il cui ruolo è quello in injectare un EOL nel render finale dell'output. E tale EOL lo generiamo platform-dependant. Il giorno 21 febbraio 2018 11:07, Tristano Ajmone <notifications@github.com> ha scritto:

…

Secondo me Polygen dovrebbe gestire in maniera diversa le sequenze di fine riga (EOL). Allo stato attuale, sta all'utente specificare se usare LF o CRLF tramite le sequenze escape \n e \r. Oggigiorno, il modo in cui vengono usate le EOL è cambiato dall'epoca in cui Polygen fu creato. Oggi l'aspettativa è che \n produca la sequenza EOL nativa del sistema operativo (CRLF su Windows, LF negli altri OS). Allo stato attuale, le EOL creano problemi quando si reindirizza l'output di Polygen ad altre applicazioni. Per esempio, pandoc si aspetta un EOL nativo, e in Windows ignorerà le sequenze LF o CR; lo stesso vale per la maggior parte delle applicazioni moderne. Il problema è che, attualmente, chi scrive grammatiche per Linux o Mac tende a usare \n per le nuove righe, mentre chi le scrive per Windows tende a usare \r\n — in realtà, nella maggior parte dei casi viene usato solo \n, ma in alcuni contesti di Windows è necessario usare \r\n per preservare la nuova riga (p.es: markdown e altri formati di testo). La soluzione ideale, a mio avviso sarebbe questa: - \n dovrebbe essere interpretata da Polygen come EOL nativa. - \r dovrebbe essere deprecata, ma preservata per ragioni di retrocompatibilità, e trattata come se fosse \n. - Occorrenze di \r\n dovrebbero essere trattate come un singolo \n (per evitare che una interruzione di riga venga interpretata come doppia) - Una nuova opzione da riga di comando dovrebbe consentire l'override della EOL nativa: -eol lf per imporre \n = LF (possibili valori per -eol: lf|crlf|cr). Quest'ultima opzione si rivelerebbe fondamentale nella creazione di script Shell o Batch, dove è necessario usare \n e \r\n rispettivamente, a prescindere dall'OS su cui si sta lavorando. In teoria, oggi CR non viene più usato come carattere EOL, veniva usato solo dai primi OS del Machintosh, ma vale comunque la pena di offrire la possibilità di utilizzarlo tramite opzioni riga di comando. Praticamente, Polygen dovrebbe normalizzare i caratteri EOL nel suo output — convertendo tutte le occorrenze di \n e \r nel carattere EOL nativo, o in quello specificato tramite opzioni, e normalizzare anche eventuali caratteri EOL introdotti tramite Ascii escapes (\010 e \013). Ho altresì notato che il comportamento di Polygen riguardo alle EOL è diverso quando si usa l'opzione -o DEST: in questo caso il carattere EOL è quello nativo dell'OS. Che ne pensi? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACcZxhmVjRcuW-yNG0VaZKZpFN-0wAw8ks5tW-rzgaJpZM4SNXWp> .

[tajmone]

L'idea mi piace, ed ha senso.

Quindi attualmente il post-processore è in grado di intercettare le attuali sequenze di escape? se una grammatica usa \n in una stringa, il post-proc. vede un token di escape all'interno di un terminale stringa, o lo vede semplicemente come il byte corrispondente?

Provo a riformulare, dato che non mi è del tutto chiaro il contesto attuale:

Le stringhe di una grammatica sono sempre terminali, giusto? Allo stato attuale come vengono gestite le escapes, arrivano al post-processore già espanse in bytes o come token? oppure all'interno dell'AST una stringa come "aaa \n bbb" viene vista come:

• un nodo stringa: "aaa"
• un nodo Escape token: \n
• un nodo stringa: "bbb"

Perché, mi pare di capire, se questo non è ciò che in qualche maniera già avviene, sarebbe comunque il modo in cui la tua proposta verrà implementata — attualmente \n e \r sono semplici sequenze escape, che vengono tradotte nel byte corrispondente, mentre le modifiche che proponi li renderebbe entrambi alias di un token speciale, per l'appunto EOL, il cui esito dipenderà dal post-processore in base a valutazioni del sistema operativo nativo.

[alvisespano]

No, attualmente il polygen non riconosce il \n, per lui è solo un escape dentro un terminale. Riprendendo il tuo esempio: il terminale "aaa \n bbb" viene visto come una semplice stringa "aaa \n bbb" (cioè così com'è scritta) sia dal generatore che dal post-processore. Non c'è nessun trattamento speciale o nessuna intelligenza aggiuntiva per manipolare gli eol ora come ora nel polygen. Infatti lo devi scrivere tra apici, come una qualunque stringa esplicitamente quotata. Per esempio: S ::= ciao "Tristano\n" Questa produzione fa generare al generatore una sequenza di 2 token di output normali: "ciao" e "Tristano\n". Dopodiché il post-processore concatena i token interponendo un carattere di spazio " " e l'output finale diventa la stringa "ciao Tristano\n". La mia soluzione invece richiederebbe di scrivere la grammatica così: S ::= ciao "Tristano" \n dove il token \n è FUORI dalla quotation ed è riconosciuto come una keyword dal polygen. Questo approccio ha un inconveniente: non rompe la retrocompatibilità (perché è una keyword nuova che semplicemente le grammatiche vecchie non usano), però non risolve il problema nelle vecchie grm. Direi allora che per prendere capra e cavoli potremmo fare entrambe le cose (sto ragionando ad alta voce): 1) un nuovo command line argument "--eol <STRING>" (del tutto simile a "--eof" che esiste già) che specifica qual'è la stringa con cui va tradotta la nuova keyword speciale \n (o come lo chiameremo) 2) un secondo command line argument "--translate-eol <STRING>" che abilita la sostituzione di tutte le occorrenze di "\n" in quello che l'utente specifica; e forse dovrebbe tradurre anche le occorrenze di "\r" e "\r\n". Pensiamoci e definiamolo meglio che possiamo, cercando di assegnare al caso di default il comportamento più comunemente desiderabile. Il giorno 28 febbraio 2018 15:16, Tristano Ajmone <notifications@github.com> ha scritto:

…

L'idea mi piace, ed ha senso. Quindi attualmente il post-processore è in grado di intercettare le attuali sequenze di escape? se una grammatica usa \n in una stringa, il post-proc. vede un token di escape all'interno di un terminale stringa, o lo vede semplicemente come il byte corrispondente? Provo a riformulare, dato che non mi è del tutto chiaro il contesto attuale: Le stringhe di una grammatica sono sempre terminali, giusto? Allo stato attuale come vengono gestite le escapes, arrivano al post-processore già espanse in bytes o come token? oppure all'interno dell'AST una stringa come "aaa \n bbb" viene vista come: - un nodo stringa: "aaa" - un nodo Escape token: \n - un nodo stringa: "bbb" Perché, mi pare di capire, se questo non è ciò che in qualche maniera già avviene, sarebbe comunque il modo in cui la tua proposta verrà implementata — attualmente \n e \r sono semplici sequenze escape, che vengono tradotte nel byte corrispondente, mentre le modifiche che proponi li renderebbe entrambi alias di un token speciale, per l'appunto EOL, il cui esito dipenderà dal post-processore in base a valutazioni del sistema operativo nativo. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACcZxq1IHzE31sAwmVCFpG0v3PPZR6J1ks5tZV_TgaJpZM4SNXWp> .