Ultimi Ritocchi Prima della Pubblicazione

[tajmone]

Ciao @alvisespano,

Sono in dirittura d'arrivo con il lavoro per il manuale italiano.

Sto rileggendo tutto il testo alla ricerca di possibili refusi. Prima di pubblicarlo aspetto il tuo benestare; se nel frattempo vuoi dargli un'occhiata anche tu.

Frase "sorta di circuiti"

A mio avviso, questa frase è poco chiara (sia nell'italiano che nell'inglese):

Questa grammatica non potrebbe produrre alcun output, poiché la generazione, indipendentemente da quale simbolo non terminale abbia inizio, incorrerebbe in un ciclo ricorsivo infinito.

Altri casi, più subdoli, possono dare luogo a sottocicli — una sorta di circuiti:

— 4.1.2 Ricorsioni cicliche e non-terminazione

Quel "una sorta di circuiti" non mi risulta molto chiaro — forse "corto circuito"? Nel paragrafo precedente menziona il "ciclo ricorsivo infinito"; in che modo quest'altro esempio differirebbe?

[tajmone]

Ciao @alvisespano, ho modificato leggerment il testo (sia in italiano che in inglese) in 2.5.2 Selezione multipla:

Selezione multipla

Si prenda l'esempio in [@sec:etichette-selezione]: la definizione di S si occupa sostanzialmente di attivare le combinazioni delle etichette S,P e M,F per Ogg. Per evitare la frequente scomodità di dover compiere simili operazioni è possibile specificare a destra del punto tra parentesi tonde una serie di etichette separate dal pipe, anziché una singola etichetta.

In entrambi i documenti S,P e M,F appaiono uniti, con la virgola che fa parte del simbolo. Io l'ho modificato in:

delle etichette S, P e M, F per Ogg.

Ci ho riflettuto un po', e so che tecnicamente parlando era giusto così com'era poiché la virgola qui può essere vista come generazione posizionale automatica. Però ritengo creerebbe meno confusione separare i simboli come ho fatto, e lasciare che la virgola sia solo punteggiatura del testo (anziché la parola chiave ,) dato che la sezione Generazione posizionale viene più avanti nel testo, e che comunque l'esempio qui discusso non dipende da essa.

Ti volevo solo chiedere conferma se a te va bene, dato che ho visto che in entrambi i documenti avevi incluso queste coppie di simboli assieme alla virgola (non spaziata) tra i tag <code>, e quindi è stato sicuramente intenzionale.

[alvisespano]

Dici che è fuorviante? C'ho messo un po' a capire di cosa parlavi: intendi dire che hai aggiunto uno spazio dopo le virgole nel testo perché la notazione "S,P" sembrava un pezzo di sintassi del polygen? Forse potremmo addirittura creare una perifrasi diversa per ovviare al problema ulteriormente:

"Si prenda l'esempio in [@sec https://github.com/sec:etichette-selezione]: la produzione sostanzialmente attiva entrambe le coppie di etichette prima di discendere nella generazione del non-terminale Ogg : sia la coppia S e P che la coppia M ed F vengono attivate mutuamente, con l'obiettivo di generare tutte le combinazioni possibili di maschile e femminile, sia al singolare che al plurale. Tuttavia, casi come questo introducono ineleganti replicazioni: la sottoproduzione (Ogg.M | Ogg.F) è replicata due volte: una volta per l'etichetta S ed un'altra per l'etichetta P. Per evitare tali replicazioni è possibile attivare molteplici etichette in una singola operazione di selezione, separandole dal simbolo di pipe. L'esempio di cui sopra si può esprimere in modo più compatto e senza replicazioni nel seguente modo:"

E poi ci mettiamo l'esempio.

Il giorno 29 gennaio 2018 10:15, Tristano Ajmone notifications@github.com ha scritto:

Ciao @alvisespano https://github.com/alvisespano, ho modificato leggerment il testo (sia in italiano che in inglese) in 2.5.2 Selezione multipla https://htmlpreview.github.io/?https://github.com/tajmone/polygen-docs/blob/draftwork/docs-src/polygen-spec_IT.html#sec:selezione-multipla :

Selezione multipla

Si prenda l'esempio in [@sec https://github.com/sec:etichette-selezione]: la definizione di S si occupa sostanzialmente di attivare le combinazioni delle etichette S,P e M,F per Ogg. Per evitare la frequente scomodità di dover compiere simili operazioni è possibile specificare a destra del punto tra parentesi tonde una serie di etichette separate dal pipe, anziché una singola etichetta.

In entrambi i documenti S,P e M,F appaiono uniti, con la virgola che fa parte del simbolo. Io l'ho modificato in:

delle etichette S, P e M, F per Ogg.

Ci ho riflettuto un po', e so che tecnicamente parlando era giusto così com'era poiché la virgola qui può essere vista come generazione posizionale automatica. Però ritengo creerebbe meno confusione separare i simboli come ho fatto, e lasciare che la virgola sia solo punteggiatura del testo (anziché la parola chiave ,) dato che la sezione Generazione posizionale viene più avanti nel testo, e che comunque l'esempio qui discusso non dipende da essa.

Ti volevo solo chiedere conferma se a te va bene, dato che ho visto che in entrambi i documenti avevi incluso queste coppie di simboli assieme alla virgola (non spaziata) tra i tag , e quindi è stato sicuramente intenzionale.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tajmone/polygen-docs/issues/1#issuecomment-361183815, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxhuuD5Fi5l9ReWk7dDLw-TD4e21cks5tPYwsgaJpZM4RdRPh .

[tajmone]

Dici che è fuorviante? C'ho messo un po' a capire di cosa parlavi: intendi dire che hai aggiunto uno spazio dopo le virgole nel testo perché la notazione "S,P" sembrava un pezzo di sintassi del polygen?

Sì, mi riferivo proprio a quello. Mi sembrava voluto, e ho dedotto che sfruttavi la sintassi della generazione posizionale, ma a questo punto del documento ritenevo più opportuno separare i simboli.

Forse potremmo addirittura creare una perifrasi diversa per ovviare al problema ulteriormente:

Grazie, il nuovo testo aiuta, semplifica la scorrevolezza della lettura. Quello precendete era molto sintetico, e in inglese un po' più difficile da articolare. Da un alto, l'esempio che segue subito dopo chiarisce il concetto, dall'altro se lo si vuole spiegare è meglio entrare nei dettagli — parto anche dal presupposto che, arrivato a questo punto, il lettore che studia il documento "tutto d'un fiato" inizia a essere affaticato e travolto dalla mole di concetti nuovi che si susseguono. Quindi tutto ciò che rende più fluida la lettura, fornendo i concetti anziché lasciarli dedurre al lettore, è un'agevolazione in tal senso.

[alvisespano]

Te la dico tutta: leggendo quel documento (in italiano, ma di conseguenza anche in inglese) mi verrebbe da riscriverlo in toto. Sono passati anni, lo spiegherei diversamente ora. D'altro canto però non ho voglia di riscriverlo tutto; e cmq è sufficientemente formale da essere di qualità buona. Quindi direi di fare così: se trovi altri passaggi oscuri (o se, leggendo qua e là li trovo io), li formulo, altrimenti il grosso lo teniamo com'è. Mi pare un compromesso ragionevole.

Alvise

Il giorno 29 gennaio 2018 20:33, Tristano Ajmone notifications@github.com ha scritto:

Dici che è fuorviante? C'ho messo un po' a capire di cosa parlavi: intendi dire che hai aggiunto uno spazio dopo le virgole nel testo perché la notazione "S,P" sembrava un pezzo di sintassi del polygen?

Sì, mi riferivo proprio a quello. Mi sembrava voluto, e ho dedotto che sfruttavi la sintassi della generazione posizionale, ma a questo punto del documento ritenevo più opportuno separare i simboli.

Forse potremmo addirittura creare una perifrasi diversa per ovviare al problema ulteriormente:

Grazie, il nuovo testo aiuta, semplifica la scorrevolezza della lettura. Quello precendete era molto sintetico, e in inglese un po' più difficile da articolare. Da un alto, l'esempio che segue subito dopo chiarisce il concetto, dall'altro se lo si vuole spiegare è meglio entrare nei dettagli — parto anche dal presupposto che, arrivato a questo punto, il lettore che studia il documento "tutto d'un fiato" inizia a essere affaticato e travolto dalla mole di concetti nuovi che si susseguono. Quindi tutto ciò che rende più fluida la lettura, fornendo i concetti anziché lasciarli dedurre al lettore, è un'agevolazione in tal senso.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tajmone/polygen-docs/issues/1#issuecomment-361359752, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxu6ROPJJm3mSBGuJrZDsqiWXGrSWks5tPhzrgaJpZM4RdRPh .

[tajmone]

Direi cha va bene così, è un buon compromesso tra una specifica formale della sintassi ed una guida all'uso della medesima tramite esempi concreti.

Non mancherò di segnalarti evntuali passaggi che potrebbero essere resi più chiari, ma in linea di massima quelli che ti ho sottoposto erano gli unici che mi venivano in mente.

Mentre traduco, e mi tocca leggere più volte le frasi del testo originale italiano, salta fuori qualche piccolo refuso di battitura che ci era sfuggito, e colgo l'occasione per correggerlo. Ma direi che quando avrò terminato con la prima bozza dell'inglese anche la versione italiana sarà stata rivista appieno.

[alvisespano]

Ma cambiale pure le frasi se vuoi: non preoccuparti. Cioè, fai pure gli interventi che ritieni necessari o ragionevoli.

Alvise

Il giorno 30 gennaio 2018 16:40, Tristano Ajmone notifications@github.com ha scritto:

Direi cha va bene così, è un buon compromesso tra una specifica formale della sintassi ed una guida all'uso della medesima tramite esempi concreti.

Non mancherò di segnalarti evntuali passaggi che potrebbero essere resi più chiari, ma in linea di massima quelli che ti ho sottoposto erano gli unici che mi venivano in mente.

Mentre traduco, e mi tocca leggere più volte le frasi del testo originale italiano, salta fuori qualche piccolo refuso di battitura che ci era sfuggito, e colgo l'occasione per correggerlo. Ma direi che quando avrò terminato con la prima bozza dell'inglese anche la versione italiana sarà stata rivista appieno.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tajmone/polygen-docs/issues/1#issuecomment-361632031, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxh1KKkqIrazItDq2HJQhLgQZscC8ks5tPzc-gaJpZM4RdRPh .

[tajmone]

(so che sei preso in questi giorni — io posto giusto per tenerti aggiornato, ma non c'è nessuna urgenza a riguardo)

Warnings di Selezione distruttiva

C'era un passaggio un po' oscuro in 4.2.2.3 Selezione distruttiva (sia in italiano che inglese) e l'ho modificato.

A un certo punto spiegava:

I casi fortunati in cui tale distruzione riguarda un’intera produzione vengono regolarmente segnalati da un warning (4.2.2.2) o un errore (4.1.4), ma nel caso in cui le produzioni distrutte siano all’interno di una sequenza non ci sarebbe modo, tramite solamente l’algoritmo di controllo delle epsilon-produzioni, di rilevare il problema, poiché di fatto non si è in presenza di epsilon-produzioni:

ma dopo l'esempio asseriva:

In tali casi viene generato un warning apposito che notifica l’utente del problema. Si badi che la correzione di tutti i warning di questo tipo irrobustiscono di molto una grammatica e talvolta possono aiutare persino a rilevare utilizzi concettualmente scorretti delle etichette.

Non era chiaro se in quest'ultimo passaggio "tali casi" si riferisse ai "casi fortunati" del paragrafo precedente, oppure a quelli dell'altro tipo ("in cui le produzioni distrutte siano all’interno di una sequenza").

L'ambiguità è data dal fatto che può essere intrepretato in 2 modi:

1. Specifica che correggendo questi tipi di warning/errori si irrobustisce la gramamtica (riferendosi a quelli dei "casi fortunati", nonché gli unici) — ovvero, i casi meno fortunati non c'entrano nulla perché tanto non sono intercettabili.
2. Spiega che per i casi meno fortunati vi è un warning apposito, diverso da quello per i "casi fortunati". E che sarebbero questi secondi warning che andrebbero corretti.

Ho dato per scontato che Polygen non sia in grado di rilevare in nessun modo le selezioni distruttive all'interno di sequenze, e che questo paragrafo volesse solo portare l'attenzione sull'importanza di correggere questi warning, così l'ho corretto in:

Quando Polygen indvidua una selezione distruttiva, genera un warning apposito che notifica l'utente del problema. Si badi che la correzione di tutti i warning di questo tipo irrobustiscono di molto una grammatica e talvolta possono aiutare persino a rilevare utilizzi concettualmente scorretti delle etichette.

spero di non aver travisato il testo.

[alvisespano]

Tranquillo Tristano, non c'è problema - io ogni tanto leggo :) E' vero che non è chiaro: ma hai capito giusto. In pratica è già un miracolo l'algoritmo che detecta i cammini che derivano epsilon-produzioni complete, figurati come faccio a sgamare epsilon-produzioni parziali. Hai capito bene quindi e la tua riformulazione va benissimo.

Il giorno 2 febbraio 2018 16:10, Tristano Ajmone notifications@github.com ha scritto:

(so che sei preso in questi giorni — io posto giusto per tenerti aggiornato, ma non c'è nessuna urgenza a riguardo) Warnings di Selezione distruttiva

C'era un passaggio un po' oscuro in 4.2.2.3 Selezione distruttiva https://htmlpreview.github.io/?https://github.com/tajmone/polygen-docs/blob/draftwork/docs-src/polygen-spec_IT.html#sec:selezione-distruttiva (sia in italiano che inglese) e l'ho modificato.

A un certo punto spiegava:

I casi fortunati in cui tale distruzione riguarda un’intera produzione vengono regolarmente segnalati da un warning (4.2.2.2) o un errore (4.1.4), ma nel caso in cui le produzioni distrutte siano all’interno di una sequenza non ci sarebbe modo, tramite solamente l’algoritmo di controllo delle epsilon-produzioni, di rilevare il problema, poiché di fatto non si è in presenza di epsilon-produzioni:

ma dopo l'esempio asseriva:

In tali casi viene generato un warning apposito che notifica l’utente del problema. Si badi che la correzione di tutti i warning di questo tipo irrobustiscono di molto una grammatica e talvolta possono aiutare persino a rilevare utilizzi concettualmente scorretti delle etichette.

Non era chiaro se in quest'ultimo passaggio "tali casi" si riferisse ai "casi fortunati" del paragrafo precedente, oppure a quelli dell'altro tipo ("in cui le produzioni distrutte siano all’interno di una sequenza").

L'ambiguità è data dal fatto che può essere intrepretato in 2 modi:

1. Specifica che correggendo questi tipi di warning/errori si irrobustisce la gramamtica (riferendosi a quelli dei "casi fortunati", nonché gli unici) — ovvero, i casi meno fortunati non c'entrano nulla perché tanto non sono intercettabili.
2. Spiega che per i casi meno fortunati vi è un warning apposito, diverso da quello per i "casi fortunati". E che sarebbero questi secondi warning che andrebbero corretti.

Ho dato per scontato che Polygen non sia in grado di rilevare in nessun modo le selezioni distruttive all'interno di sequenze, e che questo paragrafo volesse solo portare l'attenzione sull'importanza di correggere questi warning, così l'ho corretto in:

Quando Polygen indvidua una selezione distruttiva, genera un warning apposito che notifica l'utente del problema. Si badi che la correzione di tutti i warning di questo tipo irrobustiscono di molto una grammatica e talvolta possono aiutare persino a rilevare utilizzi concettualmente scorretti delle etichette.

spero di non aver travisato il testo.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tajmone/polygen-docs/issues/1#issuecomment-362612487, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxrvsjBIo-y4HiZaQTwlvaXp2MWwLks5tQyWBgaJpZM4RdRPh .